In this pull request, @CODE, @INLINE and @FILE bindings are added.
It could be used in snippet properties that run through getChunk (e.g. a tpl property on a snippet, even if that snippet was not built to support bindings), as well as in standalone tags. It also adds support for {{ }} style tags, which would be needed for the @INLINE binding to avoid confusing the parser with nested elements.
The PR has some example syntax.
From a code point of view, I don’t immediately see much issues. It needs to be rebased for 3.x and some issues may come up during testing and more thorough reviews, but simply put I’m just undecided on wether or not this is something that we should incorporate in the core.
(That doesn’t mean I’m against it, I’m just undecided.)
It’s somewhat inspired by pdoTools/Fenom, so there is some precedent for this type of syntax (altho fenom uses single brackets { }).
But that’s not syntax I typically use myself, being oldschool and prefering to create actual elements when I need them. I barely use static elements and have never used the automatic static elements introduced in 2.7, so I’m not sure how well this covers what people want to see and if it’s going to be a pain in the behind to maintain the next 5 years or not.
I’d like to see the MAB reach consensus on this topic to determine if it’s something that fits the MODX long term strategy or not.
The overarching MODX principles don’t give a clear answer either; in some way it may benefit the “any input => any output” point by allowing the input to come from different places more easily, but I also see it adding additional surface for shooting yourself in the foot with additional syntax.