On 23-Oct-08, at 3:35 PM, Chris P. wrote:
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:
- I decide to use your tag instead of creating my own special purpose
if_ and unless tags. I document it in my README
- Like some existing extensions do, I inject a page or a snippet or a
layout into the database that uses my extension and yours
- A user installs my extension because my announcement was so mind
blowingly awesome but doesn’t really read the README
- 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.
<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.
if_ tag, the contents of the tag is executed when block returns
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. 