On 22/07/2016 16: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.
I told about it in previous messages, when explained why function
autoloading is another problem - this is not a problem to create a
function, the problem is to copy-paste it in 90% places of output data.
The goal is to remove copy-paste for HTML escaping (so it will become
automatic) and possible XSS when this copy-paste is missed. If we can get a
work with other contexts, it will be just a good addition.
I missed that from the rfc. I'm conflicted with this one. For you php
"More than 90% of output data - is data from DB and must be HTML-encoded."
I have no idea how you came with this, even with applications or
websites I'm working on not using a template engine this is far from the
truth.
especially now that more ans more web application are consuming json
API, the backend often produce mostly json & xml. at that you can add
csv and pdf sometimes used for reporting, invoicing, etc. then there is
js ads
so, if I'm used to only using <?* $data ?> for html, what will make me
think about setting the different context on other places ? I'll
probably end up with html encoded data in my csv files instead.
If you can pass a variable as the escaping method
Second variable is not escaping method. It is a context. Escaping function
can handle this context as it wants.
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?
I don't think "json" escaping should produce an array, the escape should
be on the output, if I have <?= [] ?> the output is Array if I have <?*
[], 'json' ?> the output should be "Array"
I don't get why it's not escaping for you, if I have a template for a js
file, I think I should be able to escape data like that:
console.log(<?* $row['data'], 'json' ?>);
what is the difference with html here ? the escape mechanism only works
on string. obviously if I want to output a json object I should manually
call <?=
json_encode(['data' => $row['data']) ?>
and finally I'll say it again, if I want to output a javascript string
inside a script tag in a html file, for me that's two nested contexts
and the escaping should not be different from one and the other
Again, focusing on simplicity:
<?php
set_escape_handler('html', 'htmlspecialchars');
set_escape_handler('json', 'json_encode');
?>
<?*html*json= $foo ?>
becomes:
<?php echo htmlspecialchars(json_encode($foo)); ?>
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.
Which begs the question, if you can verify that the call to
set_escape_handler comes before the template, then can you also be sure
that a function definition will come before it, and just call a function
directly?
Sorry, not sure if I understand your question. What do you mean in 'call a
function directly'?
If you mean <?= $this->escape($myValue, $myContext) ?> then the goal is to
remove this copy-paste.
