> sticking the escaping types after the output makes it hard to spot what's
going on with anything other than a simple variable. e.g. <?*
$this->renderView($thing->getViewName(), 'html'), 'js' ?>
In Twig escapers and filters are also written after a variable, and this is
not confusing for many users.
{{ render(thing.viewName, 'html') | escape('js') | somefilter }}
> Because it's not obviously part of the <?* operator, someone might think
the escape parameter can be used elsewhere: <?php echo
'<blink>oops</blink>', 'html' ?> Operators don't normally have a list of
arguments.
Just a default variable, nothing complicated.
If they write echo like this, they will notice 'oopshtml' and then correct
this contstruction.
Binary operators have 2 arguments (add($a, $b), escape($string, $context)),
'for' has 3 arguments.
And this is the reason why I want it to be a call of function with constant
name. This is very clear - <?* $str, $context ?> turns into
some_escape_function($str, $context).
> What happens if you mistype the argument? <?* $foo, 'hmtl' ?> Or with the
current proposal's use of '|', what if you get that syntax wrong? <?* $foo,
'html || js' *?> <?* $foo, 'html, js' ?>
Exception: Unknown context 'hmtl'.
Exception: Unknown context ''.
Exception: Unknown context 'html, js'.
If the handlers for these contexts are not set, of course.
> if you're mentioning the whole function name, you can just call it already
> <?*html= $foo ?>
Do you mean the function autoloading? What is the difference with not-fq
name 'PHPEscaper' then?) And how to use an escaper like [$this, 'html'] ?
> JS escape only; not sure if this should encode as JSON, or just a JS safe
string; maybe <?*json= $foo ?> as well / instead...
This looks unclear for me - why I cannot use json for strings and what if
my variable sometimes is an array, sometimes a string?
> The biggest use case for this is people who *aren't* using a framework
... so customising the definitions is going to be the exception, not the
rule
They can setup their escapers once, this is not a problem, but the problem
is e.g. default flags for html escaping.
Customization is required.
> If we make it too flexible, we're basically inventing a new templating
language
We cannot forbid a customization, so any custom escaper is a kind of new
templating language.
The operator must be simple for use. If someone wants to create new
templating language in his application, let he create. It will be in
application, not in PHP.
> The trick with the magic class name and namespace aliasing is neat, but
feels likely to confuse a lot of users
Yes, I have to agree. Maybe more better way is to make it similar to
set_error_handler() - not for context as it is in RFC, but for 'escape'
callable.
<?php
// somewhere in application
set_escape_handler(function($string, $context = 'html'){
...
});
// or
set_escape_handler([$this, 'escape']);
?>
<?* $myValue, $myContext ?>
Libraries can save and restore original handler when rendering their
templates. If the library meet unknown context during work, it can call
original handler from inside its handler. Frameworks and CMSs can provide
an internal syntax for registering custom handlers from modules and
libraries.
The reason for creating not-fq name 'PHPEscaper' was a possiblity to use
custom handler in some library, without taking care about application
handler. But maybe this will bring more problems than it solves...
We cannot use a stack like spl_autoload, because escaping function can
return only a string, not true or false.
There can be used a special variable "html($str, $context, &$handled)",
return an array [$str, $handled], or throwing and catching exceptions that
can reduce performance. All variants look as inappropriate.
So, it seems, the easiest way is with set_escape_handler().
