On 10/05/2016 05:05 PM, Korvin Szanto wrote:
On Tue, Oct 4, 2016 at 4:18 PM Sara Golemon <[email protected] <mailto:[email protected]>> 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/3df62d34-af9d-c6b3-5595-07fd246ac8a5%40garfieldtech.com. For more options, visit https://groups.google.com/d/optout.
