On Jul 8, 2008, at 2:27 PM, Sean Cribbs 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:


Your thoughts?

In that case, I'd go back to:


because I'd want all of the additional options to be the same setting for the sake of simplicity: false (like inherit). So that 'any' would be false by default. I think there's a downside to r:content having inherit default to false and contextual default to true... its harder to remember and understand. The horses have left the barn on that one, but I think the goal should be to have extra options either all on or all off by default.
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