Adam,

Thank you so much for your feedback. I like your thinking. I do have some questions and comments for you and the rest of the gang. See below...


While the proliferation of tags can be bad for users, Radiant lacks any mechanism for ensuring dependancies are installed making using this extension within my own potentially destabilizes my extension. This is a sufficiently fundamental thing that I'd be happier to see it rolled into the core than distributed as an extension.

If I can get this thing refined and enough users dig it, I'd love to see it or some similar concept core. But I'm not sure I understand how my extension could destabilize your extension. I certainly wouldn't want that. Can you explain what you mean?

As an aside, I think that there is a place for purpose specific conditional tags. Personally I'm not convinced that

<r: if cond="content['body'] exists?"> blah </r:if>

is more readable than

<r:if_content /> blah </if_content>

to someone who isn't already a developer of some sort who understands what a conditional is.

I agree... with a couple of caveats.

   * I'm sure I'd say the same about:

     <r:if_content part="part name, other part name" find="any">

     vs,

     <r:if cond="content includes_any ['part name', 'other part name']>

   * <if_content part="my part"> isn't clear -- specifically that it
     test for *existence* (as opposed to whether the part has any
     content -- whether it's blank).

     Worse still is the inconsitency of meaning across tags.  For
     instance, based on <r:if_content>, you'd think
     <r:if_ancestor_or_self > means: "if an ancestor of the page exists
     or if this page exists" (which is nutty) but it means: "if *this
     contextual page is* the actual page or one of the actual page's
     parents"  Ok then, so <r:if_parent> must mean "if this contextual
     page is a parent of the actual page."  Nope.  Now have your
     clients guess what <r:if_url> does.


I think that there is a place for these tags and I'd love it if there was an easy way to use this to create both if_ and unless_ tags. Something like:

conditional_tags "my_tag" do |tag|
  #return a boolean
  false
end

which would then create if_my_tag and unless_my_tag tags. For the if_ tag, the contents of the tag is executed when block returns true, and the reverse happens for the unless_ tag.

This is interesting. I'll have to think about this. Essentially what you're going for here is the removal of the attributes (something I agree with). I bet my extension would be more comfortable if only you could write:

 <r:if content exists?>


I'm just concerned that the lack of descriptivity (word?) -- <r:if_xxx> is too limiting. So instead, we end up cranking out <r:if_yyy> and <r:if_zzz> or tacking on attributes for special cases.



This syntax combined with your generic tags would probably provide the right level of excellence for all classes of user.

Now all we need is to simplify looping, another common tag type that could be simplified for extension authors.


True -- but I think *far* less necessary.



-Chris
_______________________________________________
Radiant mailing list
Post:   Radiant@radiantcms.org
Search: http://radiantcms.org/mailing-list/search/
Site:   http://lists.radiantcms.org/mailman/listinfo/radiant

Reply via email to