I don't think there should be a PSR to dictate how and if output is escaped. It also shouldn't dictate specific tests. If you are not sure about the security of a template engine output escape function there are better ways like a security audit and sending a PR with fixes or tests.
An escaping output PSR is pretty much useless since in the frameworks that I know they all use a template engine. If you want to do something useful you have to do it on the template engine level. Because of my involvement with zend-expressive I know a bit about template engines and how to support multiple template engines. If there is anything where you could apply an useful standard, it is the render interface. To get an idea have a look at this: https://github.com/zendframework/zend-expressive-template/blob/master/src/TemplateRendererInterface.php. This is basically the glue that makes Twig, Plates and zend-view compatible with zend-expressive. But having such an interface still doesn't dictate or guarantee consistent output escaping and security. Because of the differences between the engines and their template language, I think it's nearly impossible to enable output escaping by default (considering you don't want to make engines a lot slower). Just my 2 cents, Geert Eltink. On Thursday, October 6, 2016 at 11:07:39 PM UTC+2, David Négrier wrote: > > Hey Woody, > > I'm pretty sure there is a lot of things that need to be discussed if we > go the template way. > > The render method could be: > > public function render(array|object $parameters) : string; > > In that case, it would be up to the implementators to adapt to the passed > parameter. This is mostly a solved problem with packages like > symfony/property_access > <http://symfony.com/doc/current/components/property_access.html> that let > you access a property of whatever underlying object/array you have. > Or the interface could dictate that the parameters MUST be an array, in > which case you could always wrap your object as a property of the > parameters array: > > $template->render(['obj'=>$myObject]); > > Anyway, I'm sure there are a lot of things that can be discussed here. The > render method could also return a PSR-7 ResponseInterface object or a strem > instead of a string... > I don't want to dive deep into the details in this thread (mostly because > it was initially about output escaping and I don't want to hijack too much > the initial theme of the post) but I'd be interested in knowing if this > approach has some support amongst the people reading this list. > > What do you think? > > ++ > David. > > > > Le jeudi 6 octobre 2016 14:15:04 UTC+2, Woody Gilk a écrit : >> >> What if my templates use objects? >> >> On Thu, Oct 6, 2016, 04:34 David Négrier <[email protected]> wrote: >> >>> Hey, >>> >>> I would simply like to give a huge +1 to Larry's answer because he did >>> nail the problem perfectly. >>> >>> Escaping is done in the template, therefore is used by template engine >>> authors. There are not a hundred different ways to do escaping and an >>> escaping PSR would really dictate an implementation which is not what FIG >>> is doing. >>> >>> On the other end, there are huge interoperability issues at the template >>> level. There are indeed a hundred different ways to write a template (Twig, >>> Blade, Mustache, Smarty, pure PHP, you name it...), but all templates have >>> in common that they take an array of parameters and that they spit out some >>> HTML (or more precisely a string of content). >>> >>> Therefore, IMHO, efforts to increase interoperability might be better >>> focused it the template level rather than at the espcaping level. >>> >>> For instance: >>> >>> interface TemplateInterface >>> { >>> public function render(array $parameters) : string; >>> } >>> >>> Such an interface could be used to abstract template rendering from the >>> actual implementation (think about rewriting all Smarty templates into Twig >>> templates in a project without touching the PHP code base, just swapping >>> the implementation of the template). Each template engine is internally in >>> charge of the escaping so we don't need to focus on that. >>> >>> ++ >>> David. >>> >>> >>> Le jeudi 6 octobre 2016 10:45:47 UTC+2, Matteo Beccati a écrit : >>>> >>>> Hi, >>>> >>>> On 06/10/2016 09:53, Alessandro Lai wrote: >>>> > Maybe the aim of this PSR should be a test suite (or at least a data >>>> > provider of common and edge cases for tests) instead of an interface: >>>> if >>>> > your escaper pass all the tests, it's PSR-x compliant. >>>> > >>>> > This could be a really good standard, which any implementer can look >>>> up >>>> > to to see if its implementation is up to the task. >>>> >>>> Still, I don't think it's a suitable goal for a PSR. We'd be defining >>>> the output of an implementation, which is more or less like providing >>>> one. What would be the benefit? >>>> >>>> >>>> Cheers >>>> -- >>>> Matteo Beccati >>>> >>>> Development & Consulting - http://www.beccati.com/ >>>> >>> -- >>> You received this message because you are subscribed to the Google >>> Groups "PHP Framework Interoperability Group" group. >>> To unsubscribe from this group and stop receiving emails from it, send >>> an email to [email protected]. >>> To post to this group, send email to [email protected]. >>> To view this discussion on the web visit >>> https://groups.google.com/d/msgid/php-fig/08a4aa53-7fd1-46db-a237-2a1d2fed43fd%40googlegroups.com >>> >>> <https://groups.google.com/d/msgid/php-fig/08a4aa53-7fd1-46db-a237-2a1d2fed43fd%40googlegroups.com?utm_medium=email&utm_source=footer> >>> . >>> For more options, visit https://groups.google.com/d/optout. >>> >> -- >> >> Woody Gilk >> http://about.me/shadowhand >> > -- You received this message because you are subscribed to the Google Groups "PHP Framework Interoperability Group" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/php-fig/2d05c125-6fbd-48b6-bb60-3f31a6c8aacf%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
