On 07/23/2016 05:23 PM, Rowan Collins wrote:
> On 22/07/2016 15:54, Michael Vostrikov wrote:
>>> The more you compare it to a function call, the less I understand
>>> how it
>> gains over just defining a function e() and writing <?= e( $foo,
>> 'html') ?>
>>> > I might as well just write "function e($string, $mode='html') {
>>> .... }"
>>> > they will already have a method of doing this
>> Yes, and they have to write a call of it everywhere. New operator can
>> remove it.
>
> This is the part I don't get. How does "using an operator everywhere"
> remove the effort of "using a function everywhere"? It's the same
> effort in both cases.
I to think that's the same effort, however using an escape operator have
one advantage imho: you can use a linter to check that all output pass
through an escaper.
it can still be wrong but its absence can be detected
thinking about escaping, it reminded me about ob_start, it takes an
optional output_callback that's called on the output data. what if the
escape operator was not limited to short tags and worked the same way
(except for the buffering part) ? it would ensure that any output within
"escape context" would be escaped, eg:
<!DOCTYPE html>
<html>
<body>
<h1><?['html']: $this->title() ?></h1>
<p>
<?php['html']:
echo $this->article()->summary();
?>
<button
onclick="document.getElementById(<?['js', 'html_attr']:
"article-".$this->article()->id() ?>).style.display = 'block';"
>read more</button>
</p>
<article id="article-<?['html_attr']: $this->article()->id() ?>"
style="display: none">
<?php[]:// this says: this one should not be escaped
echo $this->article()->htmlContent();
?>
</article>
</body>
</html>
and if it's explained that work on the output string data, there is no
doubt about that <?['json']: [] ?> should result in "Array"
>
>
>> The goal is to remove copy-paste for HTML escaping (so it will become
>> automatic)
> > ...
> > the problem is to copy-paste it in 90% places of output data.
>
> If somebody can't type "e(" and ") without copying and pasting, then
> they're going to have a hard time writing any meaningful code.
I think means that it's repeated all over the place, not necessarily
that it's not written by hand. that said, I'd rather have that repeated
all over to make sure you think about the correct context at all times
>
>
>>> On the other hand, if I have an array and ask for it to be
>>> HTML-escaped,
>> nothing iterates the array for me, it will just print "Array". So if
>> I ask
>> for it to be "JS-escaped", why should it magically produce a JSON array?
>> Yes, I agree, I methioned this in RFC - JSON is not escaping, it is
>> encoding in special notation.
>> This is one of the reasons why I was disagreed with the need to support
>> multiple contexts.
>> So, the question is up again - do we really need multiple contexts?
>
> The reason multiple contexts are needed, in my opinion, is the false
> sense of security of saying "we have built-in escaping", but actually
> meaning "we have built-in HTML escaping". If the idea of this feature
> is to make good escaping habits second-nature to users who don't have
> a templating system, then there's a responsibility to remind them that
> not all contexts are created equal.
>
> As for what "JS-escaped" should mean, why not just backslash-escape
> quote marks, like you'd ampersand escape double quotes in HTML?
>
> <?php $foo = "World's End"; ?>
> var foo='<?*js= $foo ?>';
>
> var foo='World\'s End';
>
>
>> Yes, PHPEscaper from RFC works that way - PHPEscaper::registerHandler().
>> But it think runtime definition with second variable is more flexible
>> way.
>> There are external contexts (HTML is one of) and internal task-dependent
>> contexts which can be combined with HTML. We cannot know all possible
>> tasks.
>> And we come again to pipe operator and twig-like syntax.
>
> More flexible to what end? Why do I need to be able to dynamically
> define arbitrarily complex expressions as the filter name?
>
> Note that what is defined in the RFC currently is *not* similar to
> Twig/Smarty, because it views the parsing of the | as *internal* to
> the callback, not part of the escaping syntax itself. It allows you to
> define an escape callback that instead uses "," as the separator, and
> I don't see why that would ever be necessary.
>
> If you have a new context, give it a name, and register it. As I say,
> this is how streams work - you don't register a callback that filters
> all filepath strings, you register a prefix for your particular stream
> type.
>
>
> Again, the stated aim of this RFC is to make correct escaping easier
> than incorrect escaping. That means providing really obvious syntax,
> out of the box, for doing the right thing.
>
> Regards,
--
Mathieu Rochette
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
