OpenEuphoria / euphoria-mvc

MVC web framework for Euphoria (https://openeuphoria.org/)
MIT License
14 stars 4 forks source link

[enhancement] template end statements should be Jinja compatible #13

Open jm-duro opened 3 years ago

jm-duro commented 3 years ago

{% end if %}, {% end for %}, {% end block %} should be written {% endif %}, {% endfor %}, {% endblock %} to be Jinja (Python-based) compatible: https://jinja.palletsprojects.com/en/2.10.x/templates/

Even PHP-based CMS use the same syntax, as October CMS does: https://octobercms.com/features

Regards

Jean-Marc

ghaberek commented 3 years ago

I'll consider this. The change is quite trivial and can still be compatible with the Euphoria-style end statements.

If you go into mvc/template.e and look at the statement definitions, you'll see they're just regular expressions.

https://github.com/OpenEuphoria/euphoria-mvc/blob/master/include/mvc/template.e#L60

Right now they look like this:

T_ENDBLOCK      = new_token( "T_ENDBLOCK",    `^{%\s*end\s+block\s*%}$` ),
T_ENDIF         = new_token( "T_ENDIF",       `^{%\s*end\s+if\s*%}$` ),
T_ENDFOR        = new_token( "T_ENDFOR",      `^{%\s*end\s+for\s*%}$` ),

Simply changing the whitespace pattern between end and block/if/for from one or more whitespace \s+ to zero or more whitespace \s* should make it compatible.

I was recently updating the documentation for templates and had written a note about then and do missing from the template statements, and I could use a similar technique to make those optional as well.

So basically you could write template statements that look like Euphoria code or Jinja code and it should work. I'm open to additional input on this before I push the changes.

jm-duro commented 3 years ago

Implementing all Jinja features would be too much work. Most important ones are those you already implemented.

elsif should be renamed elif

Eventually {% raw %} ... {% endraw %} to display Jinja items without interpreting them might be useful.

Filtering with pipes as in {{ variable | upper }} might be difficult to implement as there might be more than one pipe involved.

ghaberek commented 3 years ago

Implementing all Jinja features would be too much work. Most important ones are those you already implemented.

Everything? No, because then we'd just be porting Jinja to Euphoria. 😆

elsif should be renamed elif

This can be accomplished with the same Regex trick as the others. By making the s in the middle a zero-or-one rule like [s]?.

Eventually {% raw %} ... {% endraw %} to display Jinja items without interpreting them might be useful.

I can do this, adding new blocks isn't too difficult with the way I've built the parsing engine. Not sure I like it being called "raw" so I might opt for another name.

On a side note, I just added a {% collapse %} block that strips excess whitespace from whatever inside. I'll push that soon. Although looking at the Jinja docs this is typically done with a pipe filter.

Filtering with pipes as in {{ variable | upper }} might be difficult to implement as there might be more than one pipe involved.

Right now, any number of filters could be implemented as functions, e.g. {{ upper(variable) }}. I can add more of these to the list of built-in functions, like upper, lower, etc. Not sure if I want to implement filters as pipes but for Jinja compatibility I certainly could. I don't think parsing a list separated by | would be too hard.