# Radiant Best Practice

**URL:** <https://www.ruby-forum.com/t/radiant-best-practice/114864>\
**Category:** Radiant CMS\
**Created:** [September 18, 2007, 11:17am UTC](https://www.ruby-forum.com/t/radiant-best-practice/114864 "2007-09-18T11:17:48Z")\
**Posts on this page:** 11\
**Page:** 1

<div class="post-metadata">

**Author:** ![sgabello](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/s/a4c791/32.png) [@sgabello](https://www.ruby-forum.com/u/sgabello)\
**Post date:** [September 18, 2007, 11:17am UTC](https://www.ruby-forum.com/t/radiant-best-practice/114864/1 "2007-09-18T11:17:48Z")

</div>

Hi,  
I’d like to know how can I use radiant at the best…

For example: I have a Homepage with a lot of boxes with same graphic.  
How can I deploy this?

My first thought was creating something like this in the body:

\<r:snippet name=“box”\>text to fill\</r:snippet\>  
\<r:snippet name=“box”\>second text to fill\</r:snippet\>

and create a snippet like this:

.... 

I know that it can’t be done… but it is my first use logic…

So… How can I do it?

My only working solution is to create a lot of childs page, all with a  
“mytext” part, put \<r:snippet name=“box”\> in each body, create a snippet  
like this:

.... 

and include all of my childs\_box in the homepage with \<r:child:each\>

Is it the right solution? Or there’s a more pratic and fast modus  
operandi, like the first I exposed?

---

<div class="post-metadata">

**Author:** ![sgabello](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/s/a4c791/32.png) [@sgabello](https://www.ruby-forum.com/u/sgabello)\
**Post date:** [September 18, 2007, 11:25am UTC](https://www.ruby-forum.com/t/radiant-best-practice/114864/2 "2007-09-18T11:25:28Z")

</div>

Andrea O. wrote:

> like this:
> 
> .... 
> 
> and include all of my childs\_box in the homepage with \<r:child:each\>
> 
> Is it the right solution? Or there’s a more pratic and fast modus  
> operandi, like the first I exposed?

Hi Andrea,

If you want to get:

.... 

multiple times, I think the way I would do it would be to create an  
extension/ tag that would take your text as input and dump it out the  
way you want it. I’m not sure that it’s the best way to do it, but  
that’s what comes to my mind right now. I don’t think (and I may be  
wrong) that you can pass parameters to a snippet like you can with Rails  
partials.

The other idea I have is that is this is required only on the home page,  
you may be able to cut down the reusability and just enter it into the  
body of the home page since in a sense, it’s a “one-off”.

Cheers,  
Mohit.  
9/18/2007 | 5:22 PM.

---

<div class="post-metadata">

**Author:** ![sgabello](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/s/a4c791/32.png) [@sgabello](https://www.ruby-forum.com/u/sgabello)\
**Post date:** [September 18, 2007, 11:27am UTC](https://www.ruby-forum.com/t/radiant-best-practice/114864/3 "2007-09-18T11:27:28Z")

</div>

I see the problem.

It would be nice to allow parametrization of snippets, but right  
now that it’s not possible. This behavior can be implemented with a  
custom extension though.

```
/AITOR
```

---

<div class="post-metadata">

**Author:** ![sgabello](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/s/a4c791/32.png) [@sgabello](https://www.ruby-forum.com/u/sgabello)\
**Post date:** [October 18, 2007, 4:56pm UTC](https://www.ruby-forum.com/t/radiant-best-practice/114864/4 "2007-10-18T16:56:03Z")

</div>

I like the idea of parametrized snippets. I hope that the core team  
considers this for future releases, i believe that the idea is simple  
and  
fits in the philosophy of Radiant.

I would suggest to add the parameters individually to the \<r:snippet\>  
tag, and to allow a body to be defined:

\<r:snippet name=“rounded-box” class=“whatever” bg-color=“blue”\>  
This is a parametrized snippet…

```
The "name" attribute is reserved. The user is free to use any 

```

other,  
and they will be passed to the snippet code, may be with a \<r:param\> and  
\<r:body\> tag:

```
<div class="<r:param name="class"> rounded"

```

style=“background-color:\<r:param name=“bg-color”\>” \>  
\<r:body\>

```
 Backdoor 0.3.0 has a <r:tag> and <r:erb_tag> that can be used as

```

parametrized snippets, but it has the known security implications.

```
/AITOR
```

---

<div class="post-metadata">

**Author:** ![sgabello](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/s/a4c791/32.png) [@sgabello](https://www.ruby-forum.com/u/sgabello)\
**Post date:** [October 18, 2007, 10:24am UTC](https://www.ruby-forum.com/t/radiant-best-practice/114864/5 "2007-10-18T10:24:47Z")

</div>

Sorry for such a late response here. Just reading through posts I’d  
missed  
while away and came across this.

Aitor Garay-Romero-3 wrote:

> I see the problem.
> 
> It would be nice to allow parametrization of snippets, but right  
> now that it’s not possible. This behavior can be implemented with a  
> custom extension though.
> 
> ```
> /AITOR
> 
> ```

This need is one of the main reasons that drove me to create my  
Vars/Conditionals Extension. In my case I had a series of wrapper divs  
that  
made up rounded boxes on my site. There were several variations, and  
some  
had different content inside and/or unique classes that needed to be  
applied. It seemed wrong to have 30 different snippets that were all  
variations on the same theme.

My goal was to make snippets more like rails helpers or partials –  
which  
meant that you needed to be able to pass (and then process) arguments.

I even wrote a special modification to the \<r:snippet\> tag for this very  
reason (though it’s not technically necessary)

In the body you’d add:  
\<r:snippet name=“box” vars=“content:text to fill” /\>  
\<r:snippet name=“box” vars=“content:second text to fill” /\>

Then in the snippet, you’d add:

.... 

If you want to get fancy, you can also pass multiple, optional  
parameters,  
like:  
\<r:snippet name=“box” vars=“content: ‘text to fill’; id: myId” /\>

and:

 \<div class="foo"\<r:if cond="vars[id]\> id=""\> 

In this case your snippet adds the id tag to your div IF you include a  
value  
for it.

Feel free to download the extension and try it out:  
[http://swankinnovations.svnrepository.com/svn/open/radiant/extensions/vars\_if/trunk/](http://swankinnovations.svnrepository.com/svn/open/radiant/extensions/vars_if/trunk/)

Hope this helps!

-Chris

On 9/18/07, Andrea O. [removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid) wrote:

> “mytext” part, put \<r:snippet name=“box”\> in each body, create a snippet  
> Posted via [http://www.ruby-forum.com/](http://www.ruby-forum.com/).
> 
> * * *
> 
> Radiant mailing list  
> Post: removed\_email\_address@domain.invalid  
> Search: [http://radiantcms.org/mailing-list/search/](http://radiantcms.org/mailing-list/search/)  
> Site: [http://lists.radiantcms.org/mailman/listinfo/radiant](http://lists.radiantcms.org/mailman/listinfo/radiant)

–  
View this message in context:  
[http://www.nabble.com/Radiant-Best-Practice-tf4472903.html#a13265682](http://www.nabble.com/Radiant-Best-Practice-tf4472903.html#a13265682)  
Sent from the Radiant - User mailing list archive at [Nabble.com](http://Nabble.com).

---

<div class="post-metadata">

**Author:** ![sgabello](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/s/a4c791/32.png) [@sgabello](https://www.ruby-forum.com/u/sgabello)\
**Post date:** [October 18, 2007, 10:22pm UTC](https://www.ruby-forum.com/t/radiant-best-practice/114864/6 "2007-10-18T22:22:59Z")

</div>

Aitor Garay-Romero-3 wrote:

> I like the idea of parametrized snippets. I hope that the core team  
> considers this for future releases, i believe that the idea is simple and  
> fits in the philosophy of Radiant.

I agree. My original goal was to create something that would fit within  
the  
core values - simplify a common task in a easily used way. This one  
gets to  
be a challenge because it reaches a little deeper into programming than  
some  
other tags.

Aitor Garay-Romero-3 wrote:

> I would suggest to add the parameters individually to the \<r:snippet\>  
> tag, and to allow a body to be defined:
> 
> \<r:snippet name=“rounded-box” class=“whatever” bg-color=“blue”\>  
> This is a parametrized snippet…

The direction I went was with declaring variables rather than purely  
passing  
parameters. I then enhanced \<r:snippet to let you declare variables at  
the  
same time (I have a standard to also just \<r:store vars=“myVar1: Chris;  
myVar2: 47; myVar3: false”\>).

The idea here was that you could access those values in a snippet but  
also  
elsewhere in the same page, or within other contexts. You could even  
set a  
variable within a snippet and then use it back within the calling page.

That’s why I named it ‘vars’ instead of ‘params’.

Overall, I like the simplicity of your modified \<r:snippet\>. But I also  
feel like it is too limited. I also have an application that needs  
variables outside the scope of snippets.

I wonder if any of the core guys have an opinion here? John? Anyone?

Aitor Garay-Romero-3 wrote:

> ```
> The "name" attribute is reserved. The user is free to use any other,
> 
> ```
> 
> and they will be passed to the snippet code, may be with a \<r:param\> and  
> \<r:body\> tag:
> 
> ```
> <div class="<r:param name="class"> rounded"
> 
> ```
> 
> style=“background-color:\<r:param name=“bg-color”\>” \>  
> \<r:body\>

I prefer my format with a single attribute for all the  
variables/parameters  
for no particularly exceptional reason. I’ll have to think more on your  
idea – it’s got merit. (Though it’s nice to not deal with any reserved  
attribute names).

I _really_ like the idea of adding content to the snippet tag that is  
consumed by the snippet (you used the \<r:body\> tag).

One thing that you didn’t address here is that once you start dealing  
with  
variable/parameters, conditionals quickly become necessary. Often you  
want  
to respond one way or another within the snippet depending on the value  
(or  
lack of value) stored in a variable/parameter.

So I ended up creating generalized \<r:if\> and \<r:unless\> tags – to give  
the  
user a protected way to respond to these variables/parameters (but also  
to  
respond to items like page.title or page.part[partName]). Do you have  
any  
suggestions here?

Aitor Garay-Romero-3 wrote:

> ```
> Backdoor 0.3.0 has a <r:tag> and <r:erb_tag> that can be used as
> 
> ```
> 
> parametrized snippets, but it has the known security implications.

It’s the security stuff that prevents me from touching backdoor. And  
it’s  
not just that I have users that I don’t trust with the full power of  
ruby –  
I don’t trust me. A bit like giving a kid a rocket launcher for  
Christmas -  
sure it keeps the bullies away but you’re asking for trouble ;-).

## -Chris

View this message in context:  
[http://www.nabble.com/Radiant-Best-Practice-tf4472903.html#a13282850](http://www.nabble.com/Radiant-Best-Practice-tf4472903.html#a13282850)  
Sent from the Radiant - User mailing list archive at [Nabble.com](http://Nabble.com).

---

<div class="post-metadata">

**Author:** ![sgabello](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/s/a4c791/32.png) [@sgabello](https://www.ruby-forum.com/u/sgabello)\
**Post date:** [October 19, 2007, 4:38am UTC](https://www.ruby-forum.com/t/radiant-best-practice/114864/7 "2007-10-19T04:38:27Z")

</div>

> > I would suggest to add the parameters individually to  
> > the \<r:snippet\>  
> > tag, and to allow a body to be defined:
> > 
> > \<r:snippet name=“rounded-box” class=“whatever” bg-color=“blue”\>  
> > This is a parametrized snippet…

Basically, featurewise it looks like what you’re after is a templating  
language like freemarker ([http://freemarker.org](http://freemarker.org)). Radius (the templating  
language used by radiant) reminds me a lot of the very early versions of  
freemarker. Freemarker macros map conceptually to radius snippets and  
layouts.

Problem is that freemarker is a java library, so not much use to Radiant  
as is, but it’s probably a good place to look for thinking of ways to  
extend radius.

I’ve actually been doing some thinking about ripping out and replacing  
radiant (or at least modularising it) lately.

Ideally, I’d love to be able to just write ERB in radiant… which would  
be fine for just me running radiant for myself on my own server - and in  
fact backdoor basically lets me do that, but it’s hardly a bright idea  
from a security point of view.

Basically, my current thoughts are to create a ‘safe erb’ - ideally  
running using \_why’s sandbox, but should be almost as good running  
under a $SAFE=4 thread. The core active-record objects would need  
to be wrapped up in a method-filtering proxy and then handed off  
to the page content as an erb script to render as it wants.

Note that this is all just thoughts at the moment… the road to  
implementing such a beast would be quite tough - it’s not something  
that could be done incrementally, which means the odds of me dedicating  
enough time to do it is fairly slim, but thought I’d throw this out  
there to get peoples hopes up.

Dan.

---

<div class="post-metadata">

**Author:** ![sgabello](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/s/a4c791/32.png) [@sgabello](https://www.ruby-forum.com/u/sgabello)\
**Post date:** [October 19, 2007, 5:55am UTC](https://www.ruby-forum.com/t/radiant-best-practice/114864/8 "2007-10-19T05:55:38Z")

</div>

I have to say that I’m pretty firmly against writing ERB in Radiant  
pages. First and foremost, we have to remember that Radiant is a CMS.  
Among the two most important features of a Rails based CMS (as  
opposed to a regular Rails application) are the promise to your less  
technically inclined users that nothing they will do will impact the  
overall system and caching.

Even with elevated $SAFE levels, it’s inviting the application logic  
into the page, threatening cacheability and simplicity for the content  
creator, and worse, bringing along all of the risks that come along  
with ERB in a standard Rails application. Only now, a non-developer  
has the ability to open up a XSS vulnerability (or any number of bad  
things).

I really would urge people to write extensions that define Radius tags  
if you need some sort of dynamic functionality – it’s what they’re  
there for. Create a new Page type, define a tag (and remember to  
escape HTML) – it’s that easy. If a developer knows how to write a  
fragment of ERB, they should be able to master the extension system  
quite quickly.

Ok, so the other point was that Radius may not be the best. It may  
have some shortcomings, and I’ve seen a few things that irk me  
(although not enough to send me running away). If anyone’s looking  
for inspiration for something better, I’d suggest StringTemplate [1].  
StringTemplate is quite strict at enforcing model-view separation.  
The accompanying paper [2] explains things really well (also see the  
introduction to the documentation [3]). Basically, it only allows you  
to 1) reference object attributes, 2) include other templates (similar  
to snippets), 3) conditionally include templates based on the presence  
of object attributes, and 4) apply a template to an array. No  
numerical evaluation, no setting of state (all that is done in the  
model where it belongs). It’s not Turing Complete, but neither is CSS  
and it does its job pretty well.

Even if you’re not using StringTemplate, I highly recommend the linked  
PDF. It has changed the way I write the ERB in my views.

And I hope I don’t sound too combative here. I’ve just dealt with too  
much PHP spaghetti to want to throw away separation so quickly.

-Andrew

[1] [http://www.stringtemplate.org/](http://www.stringtemplate.org/)  
[2] [http://www.cs.usfca.edu/~parrt/papers/mvc.templates.pdf](http://www.cs.usfca.edu/~parrt/papers/mvc.templates.pdf)  
[3] [http://www.antlr.org/wiki/display/ST/Introduction](http://www.antlr.org/wiki/display/ST/Introduction)

---

<div class="post-metadata">

**Author:** ![sgabello](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/s/a4c791/32.png) [@sgabello](https://www.ruby-forum.com/u/sgabello)\
**Post date:** [October 19, 2007, 8:27am UTC](https://www.ruby-forum.com/t/radiant-best-practice/114864/9 "2007-10-19T08:27:34Z")

</div>

Just read through that pdf. I’m mainly in agreement with his commentary  
of the current field of template engines - though he does lose me a bit  
on his ‘StringTemplate is totally the best thing ever’ conclusions  
(his alternating table row colours example (9.2) especially looks like a  
horribly stupid result to me). For the most part, his style is actually  
quite similar tomy own style when using freemarker, but I err on the  
side of discipline rather than constraint (which is also why I’ve  
choosen  
ruby over java for every piece of code that I could in the last few  
years)

The main reason I want to look at this is to try and make sure that if  
we do want to take radius out of the equation, that our code isn’t tied  
in so tightly that you can’t switch out the template renderer. The only  
way to make sure that we’re not doing that is to try replacing the  
template renderer and seeing how much things break.

My plan for safe-level erb isn’t to expose the page model directly to  
the  
template (the fact is that ActiveRecord classes are unusable at  
$SAFE=4),  
but to have a mechanism for declaring which attributes and collections  
of  
a Page to be exposed to the template. ERB is just my first choice as it  
takes away the need to write my own template parser.

I think the current situation where you can’t iterate over a collection  
or perform a simple conditional check without adding new tags is pretty  
poor and the main reason why things like Backdoor exist.

> there for. Create a new Page type, define a tag (and remember to  
> escape HTML) – it’s that easy. If a developer knows how to write a

That ‘remember to escape HTML’ is one of my issues with radius -  
escaping  
should be the default, not vice-versa, but the way that radius builds  
strings would make that virtually impossible (doing it in ERB isn’t much  
easier, but possible).

…speaking of which I just realised where an XSS vulnerability is.

> Among the two most important features of a Rails based CMS (as  
> opposed to a regular Rails application) are the promise to your less  
> technically inclined users that nothing they will do will impact the  
> overall system and caching.

Exposing limited objects in a safe ruby environment shouldn’t harm that  
goal. I definitely don’t want a world where response header changes and  
page updates are happening within the template content.

Dan.

---

<div class="post-metadata">

**Author:** ![sgabello](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/s/a4c791/32.png) [@sgabello](https://www.ruby-forum.com/u/sgabello)\
**Post date:** [December 13, 2007, 7:08pm UTC](https://www.ruby-forum.com/t/radiant-best-practice/114864/10 "2007-12-13T19:08:29Z")

</div>

It’s interesting. I would change some names you use, but overall the  
idea is nice. Now, it’s up to Radius developers to decide if it’s worth  
including this feature. I believe so.

```
Thanks for sharing!

/AITOR
```

---

<div class="post-metadata">

**Author:** ![sgabello](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/s/a4c791/32.png) [@sgabello](https://www.ruby-forum.com/u/sgabello)\
**Post date:** [December 13, 2007, 6:58am UTC](https://www.ruby-forum.com/t/radiant-best-practice/114864/11 "2007-12-13T06:58:45Z")

</div>

Aitor Garay-Romero wrote:

> I like the idea of parametrized snippets.

Here is how I have implemented this idea.

In the tag plugin:

```
    define_tag "snippet:pageattr" do |tag|
        attr_to_get = tag.attr['attr_to_get'] || nil
        if attr_to_get.blank?
            %{<b>NO ATTR SPECIFIED</b>}
        else
            ret_val = nil
            content = 

```

tag.context.instance\_variable\_get(:@tag\_binding\_stack).detect{ |slot|  
slot.name == “snippet”}  
if !content.blank?  
ret\_val = content.attr[attr\_to\_get] || nil  
if ret\_val.blank?  
%{ **COULDN’T FIND ATTR #{attr\_to\_get}** }  
else  
%{#{ret\_val}}  
end  
else  
%{ **ERROR IN GETTING CONTENT** }  
end  
end  
end

The snippet tag in the page:

\<r:snippet name=“a\_snippet” attr\_one=“hello” attr\_two=“goodbye” /\>

The pageattr tags in the snippet:

\<r:pageattr attr\_to\_get=“attr\_one” /\>  
\<r:pageattr attr\_to\_get=“attr\_two” /\>

This will display “hello” and “goodbye” in the snippet.