Thanks for your response and kind words, Jim.  See my comments below...

Jim Gay wrote:
I agree that the list of if_this unless_that can get very long, but there is a benefit in that the intentions of the code are clear. I remember seeing emails about your extension and being very interested in the past, Chris, but I didn't have time to take a look at it.

I agree with the principle that a single r:if would make life simpler, but my gut reaction is that it starts looking less natural. But maybe I'd feel better with some nomenclature changes.

Please resurrect it. I've got some questions that might just be cleared by using it.

At this point, I plan to bring it back. I have two issues I'd like to address and time is the big factor.

Something just bugs me when I see shortcuts such as the attribute "cond" when I feel like "condition" would be clearer. I think that in a system like Radiant, which seems to have some good coverage with non-technical users, clear intentions are important.

I agree. Actually, in my original version I permitted both cond="xxx" and condition="xxx" to allow for quicker typing among the geeks.

I would scope the variables stuff more explicitly, such as
<r:variables:store> and <r:variables:output>
Because, although I haven't done it yet, I think a simple ecommerce web store would be a nice extension and <r:store> would make sense there.

Good idea. Other variations included <r:set var[s]="x: 1; y: 20"> I'm now thinking that a better approach would be <r:vars x="10" book="John" chapter="3" verse="16" />. It seems more readable.

By the way, I opted to only create a specific variable setter but a generalized getter. Since my <r:if condition="page.title == foo"> had to be able to evaluate page.title to compare it, it seemed natural to create a way to output anything evaluation-able. So you can also:
   <r:puts value_for="page.title" />  or
   <r:puts value_for="page.part[my part]" />

Now, these two examples overlap with the existing <r:title> and <r:content part="my part"> which are more concise, but it makes it nice for extension writers to easily offer:
   <r:puts value_for="this.that" />

(more on "this.that" below...)

You mentioned using <r:if cond="children.index = 1"> but should that have a double equal (==)?

It currently allows "x=1", "x ==1", or "x equals 1" since radiant is geared at the non-programmer. Incidentally, "x == y" is also permitted.

Does it allow the use of RegExp matching with =~ ?

It currently allows "x matches /regexp/" and "x match /regexp/" but also including "=~" would be trivial.

In addition, the following comparisons are permitted:

   * "x exists", "x exists?", or just "x"
   * "x blank", "x is_blank", or "x blank?"
   * "x empty", "x is_empty", or "x empty?"
   * "x not 12" or "y != 'my string value'"
   * "x < y" or "1 lt 2" (> and gt also available)
   * "y <= 'A'" or "x lte z" (>= and gte also available)

Does the extension provide a way to easily describe how to parse things like "children.index" or "this.that" ?

No -- though I've always considered this critically needed. This is where I got stuck as my ruby and radiant chops just weren't there. I'd love to look into it now that I am much more familiar with radiant but this is also the place I would very much welcome help.

Basically, my code parses the condition into left and right symbols and the comparison element and then hands off the symbols to be evaluated. I'd want extension writers to be able to add in code to define how to evaluate their own custom symbols. I need a good mechanism for that. So if you define a current_shopper.index, you could instantly offer:
   <r:if condition="current_shopper.index equals 1000000>
       <strong>Hurray! You're the millionth shopper!</strong>

Does it have the equivalent unless tag?

Sure does.

I disagree with John's suggestion too. <r:if_index in="-1,-2,-3"> makes me think, "huh?"

Just this evening I was walking a client through parts of their Radiant site. I always say something to the effect of "you can always contact us when things need to be changed, but this is how its done..." Some people speak up and say "Ok, forget it, I don't need to see that" while others pay attention. When I walked through a few examples we have with <r:if_content part="part_name"> the client said, "Oh, cool". The intentions of that code are very clear and I have little fear (depending on the user) that someone can screw that up.

That's not to say that everything should be dumbed down, but to me something like <r:if_first group_of="10"> is very friendly. So a DRYer <r:if> would be nice, but I think a friendly dialect (for lack of a better term) is very important.

What he said.

I too, want to see maximum usability and comprehension for the non-techie. And I *certainly* welcome input as to how to improve the wording/syntax/approach used here to deliver on this.


Radiant mailing list

Reply via email to