Re: [Radiant] if_content multiple parts (was if_content with inherit)
Awesome. I didn't want to assume that you'd have time, so I thought some +1s from the list would show support. Thanks. On Jul 15, 2008, at 2:03 PM, Sean Cribbs wrote: Jim, I'm working on the core this week so I'll pull in those changes. Sean Jim Gay wrote: I'm eager to see these additions in the core, but rather than just bugging them with pull requests would anyone like to give it a +/- 1 for adding in for 0.6.8? The changes in my repo add: 1) inherit = "true" to r:if_content and r:unless_content to work just like the r:content tag. 2) allow a list of parts to find such as 3) add a find="any" or find="all" to change the condition when listing multiple parts On Jul 10, 2008, at 3:05 PM, Jim Gay wrote: I ended up going with find="any | all" because it just made more sense when applied to unless_content. My additions are here: http://github.com/saturnflyer/radiant/tree ___ Radiant mailing list Post: Radiant@radiantcms.org Search: http://radiantcms.org/mailing-list/search/ Site: http://lists.radiantcms.org/mailman/listinfo/radiant ___ Radiant mailing list Post: Radiant@radiantcms.org Search: http://radiantcms.org/mailing-list/search/ Site: http://lists.radiantcms.org/mailman/listinfo/radiant ___ Radiant mailing list Post: Radiant@radiantcms.org Search: http://radiantcms.org/mailing-list/search/ Site: http://lists.radiantcms.org/mailman/listinfo/radiant
Re: [Radiant] if_content multiple parts (was if_content with inherit)
Jim, I'm working on the core this week so I'll pull in those changes. Sean Jim Gay wrote: I'm eager to see these additions in the core, but rather than just bugging them with pull requests would anyone like to give it a +/- 1 for adding in for 0.6.8? The changes in my repo add: 1) inherit = "true" to r:if_content and r:unless_content to work just like the r:content tag. 2) allow a list of parts to find such as 3) add a find="any" or find="all" to change the condition when listing multiple parts On Jul 10, 2008, at 3:05 PM, Jim Gay wrote: I ended up going with find="any | all" because it just made more sense when applied to unless_content. My additions are here: http://github.com/saturnflyer/radiant/tree ___ Radiant mailing list Post: Radiant@radiantcms.org Search: http://radiantcms.org/mailing-list/search/ Site: http://lists.radiantcms.org/mailman/listinfo/radiant ___ Radiant mailing list Post: Radiant@radiantcms.org Search: http://radiantcms.org/mailing-list/search/ Site: http://lists.radiantcms.org/mailman/listinfo/radiant
Re: [Radiant] if_content multiple parts (was if_content with inherit)
I'm eager to see these additions in the core, but rather than just bugging them with pull requests would anyone like to give it a +/- 1 for adding in for 0.6.8? The changes in my repo add: 1) inherit = "true" to r:if_content and r:unless_content to work just like the r:content tag. 2) allow a list of parts to find such as 3) add a find="any" or find="all" to change the condition when listing multiple parts On Jul 10, 2008, at 3:05 PM, Jim Gay wrote: I ended up going with find="any | all" because it just made more sense when applied to unless_content. My additions are here: http://github.com/saturnflyer/radiant/tree ___ Radiant mailing list Post: Radiant@radiantcms.org Search: http://radiantcms.org/mailing-list/search/ Site: http://lists.radiantcms.org/mailman/listinfo/radiant
Re: [Radiant] if_content multiple parts (was if_content with inherit)
I ended up going with find="any | all" because it just made more sense when applied to unless_content. My additions are here: http://github.com/saturnflyer/radiant/tree ___ Radiant mailing list Post: Radiant@radiantcms.org Search: http://radiantcms.org/mailing-list/search/ Site: http://lists.radiantcms.org/mailman/listinfo/radiant
Re: [Radiant] if_content multiple parts (was if_content with inherit)
On Jul 8, 2008, at 9:08 PM, Chris Parrish wrote: Jim Gay wrote: On Jul 8, 2008, at 8:16 PM, Chris Parrish wrote: 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? (notice that the name "part" is singular) 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 What do you do when more than one of those is used? Well certainly you'd require only one of those attributes but that's not terribly hard logic. I see it as something akin to tags requiring an attribute and giving an error if the user leaves it out. I should have mentioned this in my last reply, but any other attributes would be optional. The implementation would be such that it would not break any existing use of if_content, so all / find / require_all / inclusive attribute is not required. And I'd rather avoid error messages for practical defaults. Too many switches to flip will lead to confusion, even if helpful messages are provided when you do it wrong. I'm just going to work on any="true" and call it a day (I can always tweak the code to do differently). This conversation was helpful. Ultimately as long as its implemented in a way that makes sense and it gets the necessary feature built I think it will be a success. When it comes down to it I'm not on the core team so they'll decide. But I wanted to get the community involved in the idea first before I added it. No worries. It's yours to build. Yes, but I'm trying to add it as a feature for the core (of which part="this, that" has already been added on edge), so it matters what the community thinks. ___ Radiant mailing list Post: Radiant@radiantcms.org Search: http://radiantcms.org/mailing-list/search/ Site: http://lists.radiantcms.org/mailman/listinfo/radiant
Re: [Radiant] if_content multiple parts (was if_content with inherit)
Jim Gay wrote: On Jul 8, 2008, at 8:16 PM, Chris Parrish wrote: 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? (notice that the name "part" is singular) 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 What do you do when more than one of those is used? Well certainly you'd require only one of those attributes but that's not terribly hard logic. I see it as something akin to tags requiring an attribute and giving an error if the user leaves it out. I'm just going to work on any="true" and call it a day (I can always tweak the code to do differently). This conversation was helpful. Ultimately as long as its implemented in a way that makes sense and it gets the necessary feature built I think it will be a success. When it comes down to it I'm not on the core team so they'll decide. But I wanted to get the community involved in the idea first before I added it. No worries. It's yours to build. -Chris ___ Radiant mailing list Post: Radiant@radiantcms.org Search: http://radiantcms.org/mailing-list/search/ Site: http://lists.radiantcms.org/mailman/listinfo/radiant
Re: [Radiant] if_content multiple parts (was if_content with inherit)
On Jul 8, 2008, at 8:16 PM, Chris Parrish wrote: 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? (notice that the name "part" is singular) 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 What do you do when more than one of those is used? I think it will muddy the use cases. I'm just going to work on any="true" and call it a day (I can always tweak the code to do differently). This conversation was helpful. Ultimately as long as its implemented in a way that makes sense and it gets the necessary feature built I think it will be a success. When it comes down to it I'm not on the core team so they'll decide. But I wanted to get the community involved in the idea first before I added it. I certainly don't want to kill the conversation about this, but I want to start adding it in. -Jim ___ Radiant mailing list Post: Radiant@radiantcms.org Search: http://radiantcms.org/mailing-list/search/ Site: http://lists.radiantcms.org/mailman/listinfo/radiant
Re: [Radiant] if_content multiple parts (was if_content with inherit)
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? (notice that the name "part" is singular) 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 <[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 [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 and 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. [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" 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 ___ Radiant mailing list Post: Radiant@radiantcms.org Search: http://radiantcms.org/mailing-list/search/ Site: http://lists.radiantcms.org/mailman/listinfo/radiant
Re: [Radiant] if_content multiple parts (was if_content with inherit)
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 [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 and 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. [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" 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
Re: [Radiant] if_content multiple parts (was if_content with inherit)
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 >> >> > [contextual="true|false"] /> >> > [inclusive="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 >> and 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. 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 not quite sure what contextual does, but I'll read about it when 0.6.8 is released... looking forward to it!) With those extra values, there's some overlap with unless_content, but I like the flexibility. Thoughts? -- Tim ___ Radiant mailing list Post: Radiant@radiantcms.org Search: http://radiantcms.org/mailing-list/search/ Site: http://lists.radiantcms.org/mailman/listinfo/radiant
Re: [Radiant] if_content multiple parts (was if_content with inherit)
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 [contextual="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 and 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" Your thoughts? In that case, I'd go back to: any="true|false" 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
Re: [Radiant] if_content multiple parts (was if_content with inherit)
Or I'm thinking that inclusive="true" might be good since we've got mostly true/false for extra attributes on r:content [contextual="true|false"] /> [inclusive="true|false"]> [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 and 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" Your thoughts? Sean ___ Radiant mailing list Post: Radiant@radiantcms.org Search: http://radiantcms.org/mailing-list/search/ Site: http://lists.radiantcms.org/mailman/listinfo/radiant
Re: [Radiant] if_content multiple parts (was if_content with inherit)
Sean, what do you think? I think either #this being the default Or I'm thinking that inclusive="true" might be good since we've got mostly true/false for extra attributes on r:content [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 and 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. On Jul 8, 2008, at 1:45 PM, Adam van den Hoven wrote: I have to agree with Tim in this. I'm traditionally bad at picking names for things like attributes but I think that its critical that the meaning be clear; Find and collect strike me as being ambiguous, I though of require but that's overloading an important word. Adam On 8-Jul-08, at 10:25 AM, Tim Gossett wrote: Or better yet #this being the default Or #this being the default This looks like the best solution to the AND / OR discussion. -- Tim ___ Radiant mailing list Post: Radiant@radiantcms.org Search: http://radiantcms.org/mailing-list/search/ Site: http://lists.radiantcms.org/mailman/listinfo/radiant
