I have put together an extension as a proof of concept and want to know what others in the Radiant community think. I'd hoped to have it more complete before releasing it but I've been very short on time and think others might be interested. I'd like your input. svn link here Let's first start with some dislcaimers/warnings: This code is very alpha and while most of it works and even has tests, there is at least one part which I am very unhappy with and should NOT be used in production (I've labeled it as "evil" in the code and would REALLY like some suggestions on the right way to do it). This code is, essentially, two extensions rolled into one. I just put them together for now for simplicity. They are: 1.) Abstracted Conditionals - instead of I've created a generic and tag that let you build your own conditional statements. Existing Radiant tags can be rewritten as such: becomes... and becomes... But more importantly, a wider range of tests becomes possible such as: or And even more important still, the goal is to allow extension developers to hook into this to yeild values for contitional testing with little added code and no new such as: or 2.) Abstracted Puts Tag - because the above must decipher symbols such as page(url) or myExtension(value), I also created a: (which is the same as Granted, the whole 'puts' bit isn't as powerful as the conditionals but it comes free. 3.) Variable Declaration - I also created a method to declare variables in a local or global context (depending on whether its a single or double tag). These variables can then be accessed later (via puts) or evaluated (via if or unless). Put it all together and the following becomes possible: -- in body -- -- in snippet: quote --
class="">

-- output --
my important string of text for quotation

Chris Parrish

To learn more, check out the README file and/or 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 out in left field. 2.) Suggestions - I have some blatent unresolved issues here that someone might see a good way to address. I have also chosen some arbitrary conventions for declaring symbols (largely based upon my limited skill with regexp). Anyone have better ideas. 3.) Contributions - at the moment the repository is read only but I'll gladly accept patches, or even grant access if you truly want to contribute. Next, this code is enough of an abstraction that I'm sure to get "Hey Chris, Why is it worth changing stuff up here?" questions so here's the rationale behind these items: THE NEED: I saw several issues/needs come together that lead me to change/add/consolidate some radius tags: 1.) I had a need to create snippets that were more like rails helpers in the sense that I wanted to pass them values (like a function) and have them behave differently based on these values. This means passing (storing/retieving) one or more values and then conditionally responding to them. Pretty basic but not built into Radiant. For instance, the user wants to call a snippet while passing a string for a CSS class. The snippet could then include the string in:
or, omit the whole class="" bit if I don't pass a value it. Or how about a snippet to stylize a block of text into a callout on the page. Just call the snippet and pass it the callout text. It then became clear that storing a value one place on the page and reusing it elsewhere on the page could also be useful. After all, there were no radius tags equivalent to storing and retrieving variables. 2.) As I started to write my own method of getting values that I'd stored with my variable declaration tag, I realized that Radiant has other tags to get stored values (after all, what's or ). Would a single get/puts/render/write (one tag to rule them all) be useful? Actually you could talk me out of this idea pretty easily because, hey, items like require additional parameters to define how to format the value. And, it's really trivial for an extension developer create their own tag to just render a value. But, reducing the number of tags that the user needs to remember is nice. An then there's this next observation... 3.) I also needed to create my own if/unless tags. Personally it bugs me that every extension that needs it must create their own and tags. This clutters up the namespace with to many tags. Worse still for the user, each has their own rules: (does test for the existance of the part or whether the part is not empty? Does work?) It also means that if a developer wants to create a conditional that performs a reg_exp match, they have to reinvent the wheel. It seems to me that the problem of parsing an expression, and comparing the values is not unique to any one test and certainly not unique to an extension. Seems like we should have just on and tag for everyone to use. And of course this suddenly makes it possible for the user check: or