On 23-Oct-08, at 3:35 PM, Chris Parrish wrote:
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?
What I mean is:
1) I decide to use your tag instead of creating my own special purpose
if_ and unless tags. I document it in my README
2) Like some existing extensions do, I inject a page or a snippet or a
layout into the database that uses my extension and yours
3) A user installs my extension because my announcement was so mind
blowingly awesome but doesn't really read the README
4) The user's site blows up because your extension is missing
The problem isn't with your extension. The problem is that there is no
standard way, no best practice to ensure at some point that the
requirements are met and gracefully allow the user to remedy that. Its
a Radiant problem.
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']>
I think that this is just at the cusp of where one leaves off and the
other starts.
* <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).
This is true. But that's a problem with the definition of either
naming (if_content_exists) or of the definition of existence. I don't
think its an argument against the value special purpose conditional
tags as a rule.
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.
This isn't caused because having special purpose conditional tags is a
a bad idea. This happened because people forget the second cardinal
rule after DRY: Use intention revealing names. These have been
shorthanded.
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.
Sorry. I was being far too brief in my example. I didn't have my
references up (Ruby is my play time/side job language; for work I'm in
the Java world) so I was going from memory.
The conditional_tags would probably be an extension to Radius, rather
than Radiant. The tag method, takes (again from memory) a "name" and a
block that is the behaviour of the tag. I'm suggesting that this is a
similar function except that it creates two tag definitions (this is
going to require some magic to get the description right for the help)
and the block only defines a portion of of the behaviour. To do
something useful you would have something like:
conditional_tags "widget" do |tag|
tag.locals.widgets.key?(tag.attr['name'] || 'foo'])
end
I suppose that it may also need a second string argument so that you
can create a widgets:each:if_widget.
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.
Unless, like me, you are creating an extension that introduces a new
model in which case you are likely to need:
each
first
last
count
has_next?
index
So less necessary but more time saving. ;)
-Chris
_______________________________________________
Radiant mailing list
Post: Radiant@radiantcms.org
Search: http://radiantcms.org/mailing-list/search/
Site: http://lists.radiantcms.org/mailman/listinfo/radiant
_______________________________________________
Radiant mailing list
Post: Radiant@radiantcms.org
Search: http://radiantcms.org/mailing-list/search/
Site: http://lists.radiantcms.org/mailman/listinfo/radiant
