Conditional conundrums
Developer Preview
Whoa, what a thread!
I think you guys are on the right track. It’s important to make a distinction between string matches and actual arrays. I quite like the CSS syntax for string matching, but it doesn’t work / is confusing and breaks backwards compatibility with arrays.
Rob’s idea is awesome. I’d add to it just following the JSON standard, so strings could be represented as:
{if url_title IN ['some-title', 'another-title']}and integers could be represented as:
{if entry_id IN [1,2,3]}And @Low replying to your comment to Rob - I don’t think there is a problem with pipe separated lists.
You can create a snippet with the contents [1,2,3] and use that:
{if entry_id in [1,2,3]}
{if entry_id in my_array_snippet}EllisLab can also support this notation for the entry_id parameter (and easily still support the old pipe-separated syntax)
{exp:channel:entries entry_id=[1,2,3]}
{exp:channel:entries entry_id={my_array_snippet}} <-- note lack of quote marks
{exp:channel:entries entry_id="1|2|3"} <-- quote marks denote old string/pipe syntaxAll you need to do to implement this is let the lexer treat square brackets as an array, and add the IN keyword to conditionals. This would be awesome and really take EE’s template parser to the next level!
Hey EllisLab,
Can you elaborate about your choices and decisions about the array syntax? Some insight about this would be nice.
I can see the IN-syntax isn’t in the current preview, which is fine, as I can now work around it with the Regex-operator. But is it still on the radar? Saving ‘till later? Or is it still just under consideration?
But is it still on the radar? Saving ‘till later? Or is it still just under consideration?
Sorry for the silence here. There’s been a lot of discussion. Definitely still on the radar, but I think we’re going to have to let it sit beyond 2.9. There are a lot of opinions and a lot of places where it would need to work perfectly for us to pull this off. What Adrian did above is what I’m thinking of in the long term (a world where strings are strings and not-strings are other things). Unfortunately right now the template parser doesn’t quite allow for it. Getting the new parser into assign_parameters takes a little more rejiggering than I’m willing to do at this point.
Low, I’m sure you can figure this out, but for anyone curious, the IN syntax can be rewritten as this (example comes from what we’re dynamically rewriting in_group() to for the next preview):
{if "1|4|13" ~ '/\b'.logged_in_member_group.'\b/'}And for posterity: I like the pythons list / javascript and php 5.4 array syntax.
Thanks Pascal!