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. Il giorno mercoledì 5 ottobre 2016 21:18:00 UTC+2, Larry Garfield ha scritto: > > On 10/05/2016 05:05 PM, Korvin Szanto wrote: > > > > On Tue, Oct 4, 2016 at 4:18 PM Sara Golemon <[email protected] > <javascript:>> wrote: > >> On Tuesday, October 4, 2016 at 9:40:03 AM UTC-7, Korvin Szanto wrote: >>> >>> Are you thinking like a text filter PSR or more of an output management >>> PSR? It sounds like a single interface with a single method to me: >>> `FilterInterface::filter($mixed): mixed;`. >>> >>>> >>>> There's many different forms of filtering: >> * Pass filtering (removing of illegal sequences) >> * Replacement filtering (transformation of illegal sequences with >> placeholders) >> * Panic filtering (raise an exception on illegal sequences) >> * Escaping (included because it's often conflated with filtering) >> >> There are whitelist and blacklist variants of these. There are also >> context sensitive issues for many of these; What's illegal in a JS context >> isn't the same as an HTML text context, or an HTML attribute context. >> >> I don't know that we need standards for these permutations, but I imagine >> it's a little more than "single interface with a single method". >> > > Fair enough, until January my head is still in FIG 2.0 mode. I still would > say that the examples you provide can fit into a single interface, but I do > see that with FIG 3.0 our scope is probably a little bit different than > lowest-common-denominator interface. > > @Chris I like the idea so far. Escaping is certainly an issue we've had in > concrete5 and it's something we've tried to solve in the past with mixed > results. One thing that I'd say is it that this kind of filtering might go > hand in hand with validation as well. > > > I'm a bit skeptical here. Such a standard would, it seems, need to > dictate less an interface and more what happens when you want to escape for > a given context. How would that be realistically different than a > universal implementation, which we usually try to avoid? > > The audience I'd see for such a spec would be, essentially, template > engine authors. Vis, how would you make it easy to plug a given template > engine (where escaping should happen) into an arbitrary framework (which > provides an escaper)? Or is the escaper part of the template engine > itself, in which case it's about what the template syntax exposes to the > user, which is... not what we usually target. > > (PSR-3's equivalent question was much more straightforward; make a given > library compatible with an arbitrary framework-provided logger, which was > quite successful. I'm not clear on what the equivalent is in this case.) > > So I think the question to ask here would be: Fabien (Twig) and Taylor > (Laravel's engine): what would help you in making your template engines > more portable to other frameworks/applications in a secure fashion, if > anything? > > --Larry Garfield > -- 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/882059cb-0c65-46f7-a4fb-7b4b84a8a003%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
