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

[Chris Parrish]

Since the all / find / require_all / inclusive attribute is both 
required and boolean (yeah I know XOR's been mentioned but I'm not going 
there), why not try to include that condition in the rest of it somehow?

<r:if_content part="my part">  (notice that the name "part" is singular)
<r:if_content any_part="my part, my other part">
<r:if_content all_parts="my part, my other part">

So in this example, you'd have 3 different possible attributes.  Its 
always easier to read one attribute name than to have to combine two or 
three into a single meaning.

This stuff really is really motivating me to get my conditionals 
extension back to life ;-)

-Chris


Jim Gay wrote:
> 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
> _______________________________________________
> Radiant mailing list
> Post:   Radiant at radiantcms.org
> Search: http://radiantcms.org/mailing-list/search/
> Site:   http://lists.radiantcms.org/mailman/listinfo/radiant