Open jm-duro opened 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.
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.
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 renamedelif
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.
{% 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