On 24/07/2016 19:09, Thomas Bley wrote:
Then why is absolutely everything in the current RFC optional and
configurable to the Nth degree?
It's one handler: set_escape_handler() (N=1)
Currently, every framework has it's own methods for escaping. To get this
together, set_escape_handler() is a good choice, similar to set_error_handler().
It's not set_escape_handler() that I'm concerned about, it's how you
actually use it in the templates. At the moment, the only thing the RFC
actually asserts about the escape handler is "it's a function with two
arguments". Frameworks are free to write all sorts of weird shit:
<?* $foo, 'html' ?>
<?* 'html', $foo ?>
<?* $foo, 'text/html' ?>
<?* $foo, [$this, 'escaper'] ?>
<?* $foo, $this ?>
<?* $foo, 'js | html' ?>
<?* $foo, 'js + html' ?>
<?* $foo, ['js', 'html'] ?>
<?* $foo, '[js, html]' ?>
<?* $foo, '{js, html}' ?>
<?* $foo, 'html(UTF-8)' ?>
<?* $foo, 'UTF-8' ?>
<?* [$foo, $bar, $baz], 'ul > li' ?>
etc
etc
If you want to provide something that will be the same in all
frameworks, then you've got to actually provide it.
OK, so I can dynamically redefine the same syntax to mean different
things at different times, within the same application. I'm not entirely
sure that's a particularly good thing.
It's the same thing with set_error_handler(), set_exception_handler(),
spl_autoload_register(), error_reporting(), etc., this concept is proven to
work.
OK, fair enough. I'm not sure it's really a killer feature, though. The
fact that I can't easily redefine "function e()" is no more of a problem
here than anywhere else in the language.
In my opinion, they are central to the feature, not an optional extra.
maybe you can join the rfc and provide the implementation?
The implementation I'm talking about is hardly complex, just some
default arguments to htmlspecialchars(). Or that would be the case, if
we didn't need to provide one escape callback to handle all possible
arguments, rather than registering for a specific strategy name.
Regards,
--
Rowan Collins
[IMSoP]
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
