Autoescape HTML?

[pbsds]

Is this feature implemented? If not: will it ever?

[enthus1ast]

Yeah, i thought about it, but it's not currently implement.
You mean html that is in a variable that on rendering is escaped, right?

[pbsds]

Correct.

Jinja2, has the problem of this simply being enabled by a autoescape=True flag, which simply assumes HTML. Other use-cases include YAML. Perhaps nimja could simply accept an "escaper function", which will escape the string output of a value unless it is marked safe?

[enthus1ast]

What do you think of this syntax:

{{ foo:safe }}

[pbsds]

Looks good! But does this mean that :safe is the token, or : + safe? In the latter case, what would happen if a : proc is defined, and safe exists?

[enthus1ast]

Good questions.
It seems that : is not a valid proc nor variable name.

so both are not valid nim (at least for now):

var `foo:baa` = "foo"

proc `:`(s1, s2: string):
  echo s1
  echo s2

"foo":"baa"
:"foo", "baa"

so i guess its save to use.

While writing the parsing function for this, i asked myself if there could be other use cases for the ":" syntax.
since pipe | and dot . are pretty much user definable and more runtime.

In constrast the :safe syntax would actually change how the parser/codegen works.
So in the case of :safe it would omit the codegen for the escaping function.

Edit: The current design of nimja would not allow | safe so easily, that's the reason i thought about :safe.
The current parsing function would allow

assert splitSafe2("foo:safe") == ("foo", true)
assert splitSafe2("foo: safe") == ("foo", true)
assert splitSafe2("foo : safe") == ("foo", true)
assert splitSafe2("foo : safe ") == ("foo", true)
assert splitSafe2("foo.baa.baz() :safe") == ("foo.baa.baz()", true)

But this needs more testing if it can clash with something.

[pbsds]

Then : looks like the best option.

[enthus1ast]

Another option would be to introduce a completely new tag:

{{. foo .}}
{. foo .}
{$ foo $}

in the current nimja, this actually looks like the cleanest solution.

$afe you know :)

[pbsds]

This would add complexity if in the future you are to implement user-defined entry and exit syntax. (see block_start_string an onward here)

EDIT: Jinja1 guide: https://svn.python.org/projects/external/Jinja-1.1/docs/build/altsyntax.html

[enthus1ast]

Oh i did not know that jinja allows to overwrite this. Interesting.

[enthus1ast]

Yeah such an Environment is a future step, but a good hint!