> > T_ECHO (echo, <?=) and T_PRINT (print) now both emit a > > ZEND_AST_ECHO_ESCAPE node in the syntax tree. > > > Interesting approach, I assume an explicit `echo $foo;` takes the > normal ZEND_ECHO route then?
No, looking at the code and tests: echo, print, and <?= all end up parsing to a ZEND_AST_ECHO_ESCAPE which emits a ZEND_ECHO_ESCAPE op code when compiled. Only inline html still compiles as ZEND_ECHO. > > Which allows instances of `HtmlString` to pass straight through a > > template without being modified (skipping the html_entities call). > > > IME once you provide an escape hatch, said hatch WILL be used. It's > not a question of IF. For sure, mistakes can be made with any system, but this helps dangerous code look *more* wrong: new HtmlString($username) is obviously wrong. And it makes the correct things require little to no extra code: <?= $username ?> is always safe. > For my part, I'd toss the idea of XHP ( > https://docs.hhvm.com/hack/XHP/introduction ) back into consideration > over something like this. XHP is pretty sweet, but I imagine there are a decent number of people that don't consider using it because it is such a departure from traditional templating. > This approach has the smell of magic quotes which we got rid of for > very good reason. XHP is much more explicit in separating markup from > data and relies far less (not at all when you do it right) on escape > hatches. Huh, I don't see similarities to magic quotes at all. That had to do with attempting to sanitize input data (plenty of problems with that). All templating systems have a means of making the default output mechanism perform escaping and a means of preventing that escaping with, this adds the same for php templates. > > -Sara -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
