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">
<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.
conditional_tags "my_tag" do |tag|
#return a boolean
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
<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.
Radiant mailing list