Radiant Best Practice

sgabello · September 18, 2007, 11:17am

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?

sgabello · September 18, 2007, 11:25am

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.

sgabello · September 18, 2007, 11:27am

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

sgabello · October 18, 2007, 4:56pm

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

sgabello · October 18, 2007, 10:24am

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:

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/

Hope this helps!

-Chris

On 9/18/07, Andrea O. [email protected] wrote:

“mytext” part, put <r:snippet name=“box”> in each body, create a snippet
Posted via http://www.ruby-forum.com/.

Radiant mailing list
Post: [email protected]
Search: http://radiantcms.org/mailing-list/search/
Site: http://lists.radiantcms.org/mailman/listinfo/radiant

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

sgabello · October 18, 2007, 10:22pm

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
Sent from the Radiant - User mailing list archive at Nabble.com.

sgabello · October 19, 2007, 4:38am

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). 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.

sgabello · October 19, 2007, 5:55am

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/
[2] http://www.cs.usfca.edu/~parrt/papers/mvc.templates.pdf
[3] http://www.antlr.org/wiki/display/ST/Introduction

sgabello · October 19, 2007, 8:27am

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.

sgabello · December 13, 2007, 7:08pm

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

sgabello · December 13, 2007, 6:58am

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.