Stricter template syntax for 4.0

[Jonathon Menz]

Hi all, there's been some discussion about template arguments here and here and looking for a few more opinions.

How do you feel about template arguments being passed to functions more or less in-tact? This means:

1. String arguments would need to be quoted
2. Types would be preserved instead of converted to a string (so things like false would work properly)
3. You could potentially include raw PHP in arguments like <% require javascript(MY_MODULE_DIR . 'js/file.js') %>

For a lot more detail on how this could look check out kinglozzer/silverstripe-stricttemplates

Also please read initial discussion here (it's short): kinglozzer/silverstripe-stricttemplates/issues/1

[Ingo Schommer]

Hey Jonathon, 

I think these are great changes. The most contentious one would be "strict braces mode" (https://github.com/kinglozzer/silverstripe-stricttemplates#strict-braces-mode). Forcing curly braces around every template variable use would require a *lot* of templates to change. I see the benefit to allowing native PHP types, but don't see a strong case for "strict braces mode". Escaping the dollar sign with a backslash for "non-eval mode" is a bit of a nuisance, but much less so than the extra typing on the most commonly used template construct. That being said, most other template languages require the same level of syntax (handlebars, Rails views, ...).

I think these changes will cause a lot of upgrade pains unless we automate the conversion.

Given we already have a parser for the "old" syntax, that should be possible to implement - just needs an owner to drive it ;)

Ingo

--
You received this message because you are subscribed to the Google Groups "SilverStripe Core Development" group.
To unsubscribe from this group and stop receiving emails from it, send an email to silverstripe-d...@googlegroups.com.
To post to this group, send email to silverst...@googlegroups.com.
Visit this group at http://groups.google.com/group/silverstripe-dev.
For more options, visit https://groups.google.com/d/optout.

--

Ingo Schommer | Solutions Architect
SilverStripe (http://silverstripe.com)
Mobile: 0221601782
Skype: chillu23

[Sam Minnée]

+1 stricter literal & variable interpretation

I'm comfortable with enforcing a stricter string syntax, and potentially allowing things like passing variables as function arguments, and even string concatenation. I'm a little worried it will lead to overly complex templates that push too much logic into the templates, but maybe i'm fighting a losing battle on that one. ;-)

-1 direct PHP pass-through

I'm not a fan of passing PHP code directly from templates to the compiled template. 

It would encourage the use of a whole bunch of hacks that we won't be testing for, meaning that people's sites will be more likely break with minor version upgrades, and will require more migration effort with major version upgrades. It would big step backwards for the project.

It stops the template language being a language, and instead makes it a chimera of PHP and something else. If we want to expand the scope of the template language, that's fine, but "hey let's just jam the entirety of PHP in here" seems lazy.

-1 Strict braces

I'm not a fan of strict braces mode either. First up it's a hugely invasive change and so it would have to be of a lot of value to be justified. Secondly, it makes the 99% case more work in order to make the 1% case less work, which doesn't make a lot of sense to me.

-1 global template config options, +1 per-ss-file options, if we must have options

I'm also not a fan of having optional flags that change the interpretation of the template, unless the configuration settings are provided at the top of the .ss file. Otherwise you're having to wander around the configuration system wondering what the setting is in order to understand how the template will work. If the config option is that at the top of the template file (e.g. in some kind of pragma comment) that would be okay.

Visit this group at https://groups.google.com/group/silverstripe-dev.

[Loz Calver]

I put a comment on the Github issue, but I’ll crosspost where I’m at.

-1 for strict braces mode in core

It’s just a thing I advocate in-house for the sake of consistency and added to the module because I could, I agree it would be a major PITA for no real benefit.

+0 direct PHP pass-through

This wasn’t really intentional, it was just a by-product of throwing that POC together in the easiest way possible. I literally renamed FreeString from core and said “that’ll do”:

Core: https://github.com/silverstripe/silverstripe-framework/blob/3/view/SSTemplateParser.php.inc#L398

Mine: https://github.com/kinglozzer/silverstripe-stricttemplates/blob/master/code/Parser.php.inc#L352

How feasible it is to attempt to parse and accept only a subset of PHP I’m not sure. What would we want to allow? Constants/class constants only? Static methods only?

I guess it comes down to what problems we’re trying to solve here versus how much work we’re making for ourselves to write and maintain this. To recap Jono’s original post, the main reasons to make these changes are:

1. true / false / null would be treated as their proper types, same for integers / floats, where they are currently cast to strings;
2. The ability to reference constants (and config values might be nice too);
3. The ability to concatenate strings (goes hand-in-hand with the above for the specific examples I was thinking of - <% require %> tags)
4. Anything I’ve missed?

Do we need to do significant work on the template parser to solve these issues? Or could we solve them in other ways?

1. Would it be possible to overcome this by testing unquoted arguments with is_bool(), is_float(), is_int() etc before we convert them to a string?
   
2. Could we have “accessors” such as <% require javascript(_const(MODULE_DIR) . 'js/file.js') %>`? Not sure if parser limitations (nested braces) would rule this out
3. Probably not too difficult if we force strings to be quoted, otherwise we’d likely have to rely on whitespace or it’ll look like a regular lookup to the parser ($Foo.Bar)
4. ???
   

Loz

[Hamish Friedlander]

Hi All,

I'm mildly for (+0.5) requiring strings to be quoted and variables to use $, and thereby allowing other simple scalar types to be used (booleans, floats, integers, maybe short-syntax arrays of those things).

I'm strongly against (-1 million :p) allowing PHP code in templates. There are several modules that allow CMS editors with various permissions to edit templates directly. It's already a bit tricky to do this securely (one of my "cool things to do" list items would be to make this easier), but allowing arbitrary PHP would make it basically impossible. eval($user_provided_string) is never a good idea.

In the example given (the requirements tag), I'd rather have a more capable requirements tag.

Hamish Friedlander

[Sam Minnée]

Well, if someone wants to work on a patch (based on Loz' work?) that enstrictens the variables and strings, and supports boolean and numeric value, that'd be good, and mergable to master.

For bonus points, providing a patch for 3.x that threw a deprecation notice on unescaped strings / varnames would be great. That will help people get their sites 4.0 ready while still working on 3.x.