[Radiant] if_content multiple parts (was if_content with inherit)

[Jim Gay]

On Jul 8, 2008, at 2:43 PM, Tim Gossett wrote:
> On Tue, Jul 8, 2008 at 2:27 PM, Sean Cribbs <seancribbs at gmail.com>  
> 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