[ANN] Variables & Conditionals Extension

Here’s a proof-of-concept extension that I’ve been working on. I
originally
hoped to have polished this all up but haven’t had the time for
development.
So, rather than stick it on a shelf, I thought I’d toss it out there in
case
it could benefit anyone. Besides, I want to find out what others in the
Radiant community think =^D.

http://swankinnovations.svnrepository.com/svn/open/radiant/extensions/vars_if/
SVN Repository Location

Quickie Overview:
This extension is essentially two extensions rolled into one. I just
put
them together for now for simplicity. It consists of:

1.) Abstracted Conditionals - instead of <r:if_myWhatever> I’ve created
generic <r:if> and <r:unless> tags that let you build your own
conditional
statements. Existing Radiant tags can be rewritten as such:

<r:if_content part=“my page part”> becomes…
<r:if cond=“page.part[my page Part]”>

and

<r:if_url matches=“regexp”> becomes…
<r:if cond=“page[url] matches regexp”>

But more importantly, a wider range of conditionals becomes possible
such
as:
<r:if cond=“page.part[my page Part] blank?”> , or
<r:if cond=“page.part[my page Part] matches /myKeyword/”>, or
<r:unless cond=“children[count] > 10”>

And, more important still, the goal is to allow extension developers to
easily hook into this so that their own custom values can be used in
conditionals. So, instead of creating new <r:if_newTagName> tags, they
could enable:

<r:if cond=“myExtension[value] empty?”> or
<r:if cond=“myCustomQuery[results] != myCustom[value]”>

All they’d have to do is provide a method in their extension to resolve
“myExtension[value]” for the conditionals to use.

2.) Abstracted ‘Puts’ Tag - because the conditionals must resolve
symbols
such as page[url] or MyExtension[value], I’ve also created a:

<r:puts value="page[url] /> (which is functionally the same as <r:url
/>,
or
<r:puts value="page[title] /> (which is functionally the same as
<r:title/>

and, of course, the extension developer can now instantly offer:

<r:puts value=“myExtension[value]” />

3.) Variable Declaration - This one could be its own extenson. It
provides
a method to declare (store) variables in a local or global context
(depending on whether its a single or double tag). These variables can
then
be displayed elsewhere (via <r:puts>) or evaluated (via <r:if> or
<r:unless>).

Examples:
Put it all together and the following becomes possible:

– in page body –
<r:store vars=“class:myClass; quote:‘my important string of text for
quotation’; author:‘Chris P.’” />
<r:snippet name=“quote” />

– in snippet: quote –

<blockquote class="">

– output –

my important string of text for quotation

Chris P.

To learn more, check out the README file and the tag descriptions (in
code
or via Radiant). Plus I’ve tried to put extra comments in the code.

What I’m hoping for:
1.) Feedback - does anybody else think that this would be useful or am I
just out in left field.
2.) Suggestions - I have some blatant unresolved issues here that
someone
might see a good way to address (see the README for more). Ideas
anyone?
3.) Improvements - at the moment the repository is read only but I’ll
gladly
accept patches, or even grant access for those that truly want to
contribute.

View this message in context:
http://www.nabble.com/-ANN--Variables---Conditionals-Extension-tf4580441.html#a13075290
Sent from the Radiant - User mailing list archive at Nabble.com.

doesn’t r:if conflict with back_door ?

-mda

Mark D. Anderson wrote:

doesn’t r:if conflict with back_door ?

-mda

That would definitely depend on whether I knew what back_door was :stuck_out_tongue: .

Sorry for my ignorance – could someone give me some guidance here
please?

Chris P. wrote:

Sorry for my ignorance – could someone give me some guidance here please?

Nevermind, I found it – great minds, I guess. Wow, quit monitoring the
group for a few months and look what happens…

Anyway, my objectives are a bit different than back_door in that:

1.) There is NO WAY I want users to have full access to ruby. I wanted
something as benign as <r:if_parent> but more flexible. I wouldn’t
build a
site for a business and then hand the secretary or office staff that
kind of
a weapon. I’m not even sure I’d trust myself if the site was important

after all, there’s no way to test whether your code breaks your live
site
without breaking your live site (no real testing environment).

2.) I want something that designers and other non-coders could use. I
don’t want them to have to learn ruby. My thoughts here are probably
closer
to John’s (can I say that?) when it comes to throwing in the kitchen
sink –
just enough and no more… done elegantly (by the way that phrase is now
trademarked, John)

3.) I wanted to give the extension developer a way to easily expose
values
from their creations and use them in conditionals – yet also control
what
can be freely accessed and what is protected. Again, flexibility with
security.

4.) I wanted something that was on a separate layer from the underlying
ruby code. That way if Radiant 4.2.5 changes the way page titles are
accessed, I only need to update my extension code – not all my static
pages
that now have Radiant-specific back_door code.

5.) On a different note, the ‘vars’ stuff I created is different
(though
I’m sure that you could build that using back_door and Ruby code).

Please don’t misunderstand me – I LIKE having back_door available but
the
needs driving this are very different (hey, that’s why we have
extensions).

So, yes, it does conflict with the <r:if> and <r:unless> tags that Aitor
created (I frankly love that he also used cond=“” – ha!) I suspect
that
most developers would opt for one OR the other, though, based on their
security needs.

View this message in context:
http://www.nabble.com/-ANN--Variables---Conditionals-Extension-tf4580441.html#a13078770
Sent from the Radiant - User mailing list archive at Nabble.com.

i think there is room for both, but personally I think it would be nice
if you left
the generic “r:if” tag to the full erb case in back_door, for those who
have both extensions
loaded.
(not that my opinion should count for much, having all of 1 week of
experience
with radiant).

-mda

i think there is room for both, but personally I think it would be
nice if you left the generic “r:if” tag to the full erb case in
back_door, for those who have both extensions loaded.
(not that my opinion should count for much, having all of 1 week of
experience with radiant).

You would be able to do that yourself - if you load backdoor after
the vars and conditions extension, the backdoor declaration of <r:if>
should kick in.