Repository navigation
Unified syntax for tag arguments [RFC] #560
Description
Tags are currently implemented as an arbitrary syntax defined in their #initialize or #parse method. Some of them use a combination of Liquid's regexes to do parsing, but not in a consistent way. This makes updating the language difficult – in particular, phasing out the lax parser.
Filters, on the other hand, are simply passed an array (positional arguments) and hash (keyword arguments), and have no say in how they were parsed. This decoupling is a huge advantage, allowing fixes and improvements to affect all filters without breaking them.
So, the idea is automatically parse tags in a certain format, for example:
arg = id colon expr | expr
tag = id (arg (comma arg)*)?
Then, the tag can access the resulting arguments (i.e. values returned from Expression.parse).
Since we do still want certain tags to have custom syntax, we can't 100% separate parsing from the tag definition. Some kind of way to extend the default will be necessary. However, since most tags don't need this (maybe none outside of the core tags?), it still allows most of the parsing logic to be decoupled.
Tags that need partially custom syntax could still take advantage of the argument parsing, e.g. the for tag:
for foo in bar reversed, limit: 4, offset: 5
Does this make sense? @Shopify/liquid @parkr
Activity
nickpearson commentedon May 12, 2015
👍 This will make implementing and maintaining custom tags a lot easier, and will make it easier for new template developers. It would also make it easier for tag developers to keep things consistent and not have to deal with parsing arguments, leaving that to Liquid.
Regarding the need for core tags to have custom parsing, like the
reversedkeyword in theforloop you showed, what if HTML-style boolean/no-value keywords were supported? (Likenowrapin<b nowrap class="x">.)Valueless keywords could be set to
true. So in your example, the resulting arguments hash of thefortag would be:I'm going off of memory here for the core tags, so sorry if this idea doesn't apply to some others.
pushrax commentedon May 12, 2015
I think having the positional arguments be treated as expressions would be the more common case (like in filters). Then many tags like
{% section 'foo' %}are trivial to implement, and also automatically work with variables or more complicated expressions.fw42 commentedon May 13, 2015
seems reasonable to me
parkr commentedon Feb 21, 2017
Hi, chiming in very late. I like this idea a lot. We do a lot of very weird parsing and have so far settled on
key=value. If Liquid gave us the arguments as a Hash if they werekey: valueand still allowed us to transform raw arguments (that don't fit thekey: valuegrammar) for backwards-compatibility, then I'd be super down. This would make our lives easier!asbjornu commentedon Jan 31, 2023
Having just implemented a few custom tags with argument syntax invented and implemented on the spot, this would be a very welcome change. Seeing how this issue is nearly 8 years old, however, doesn't make me optimistic about its fate. What is the current status?