On Jul 8, 2008, at 2:43 PM, Tim Gossett wrote:
On Tue, Jul 8, 2008 at 2:27 PM, Sean Cribbs <[EMAIL PROTECTED]>
wrote:
Or I'm thinking that inclusive="true" might be good since we've
got mostly
true/false for extra attributes on r:content
<r:content [part="part_name"] [inherit="true|false"]
[contextual="true|false"] />
<r:if_content [part="part_name, other_part"] [inherit="true|false"]
[inclusive="true|false"]>
<r:unless_content [part="part_name, other_part"] [inherit="true|
false"]
[inclusive="true|false"]>
inclusive="true" being the default (meaning AND)
Would either of those be clear to everyone?
I'd personally opt for the first (select="all") for clarity of
meaning.
I'm tempted to shy away from all of this and create a new tag like
<r:if_any_part part="one, two"> and <r:if_all_parts...> but I
think that
that will add more complexity in the long run. I don't think the
answer is
more tags. If the r:if_content chooses a reasonable default and
provides an
easy override with select="any" then communicating its use and
purpose to
users will be relatively simple.
I agree that adding a boolean attribute would stay in the spirit
of the
original tags. I'm not sure if 'inclusive' is the clearest but
it's a good
start. Some other options:
all="true|false"
requireall="true|false"
Of these two, I like requireall="true|false"
Your thoughts?
I think find="all|any" is the clearest of what we've discussed so far.
Perhaps, but I think any="true | false" is pretty clear.
Making the attribute's value boolean for the sake of conformity
doesn't seem
to outweigh clarity. Also, what if we want to add something with the
effect
of find="XOR" or find="NOR" or find="NAND"? If we were to add all of
these,
we'd have
I'm currently trying to implement based on my real-world needs.
Anything hypothetical is probably not worthwhile.
<r:content [part="part_name"] [inherit="true,false"]
[contextual="true,false"] /> (I'm not quite sure what contextual
does, but
I'll read about it when 0.6.8 is released... looking forward to it!)
This already exists in 0.6.7 (and previous versions I believe) so take
a look at your "Available Tags"
<r:if_content [part="part_name,other_part"] [inherit="true,false"]
[find="all,any,either,neither,none"] />
<r:unless_content [part="part_name,other_part"] [inherit="true,false"]
[find="all,any,either,neither,none"] />
With those extra values, there's some overlap with unless_content,
but I
like the flexibility.
Thoughts?
I find that confusing and unnecessary. If you have a real example of
where you have already had the need for something like that I'd say
there's an argument for it, but I think that's way more complex than
anyone would regularly need. In my opinion it would be fine as an
extension.
if_content (the next version) takes a list of parts, not just 1 or 2,
so 'either' and 'neither' don't really make sense in there. 'none' is
handled by unless_content, so we're back to 'all' and 'any' (in my
opinion).
-Jim
_______________________________________________
Radiant mailing list
Post: Radiant@radiantcms.org
Search: http://radiantcms.org/mailing-list/search/
Site: http://lists.radiantcms.org/mailman/listinfo/radiant
