On 10/5/16 12:17, Larry Garfield wrote:
On 10/05/2016 05:05 PM, Korvin Szanto wrote:
On Tue, Oct 4, 2016 at 4:18 PM Sara Golemon <p...@golemon.com
<mailto:p...@golemon.com>> 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?
Escaping would not make Twig more "portable" (whatever that means),
that's for sure.
To give some feedback from a project, Twig, that has an escaping
mechanism, you need to keep in mind that this is very performance
sensitive as it is potentially called hundred of times in a page. So,
this part of the code should be highly optimized (Twig only use one
function here, no abstraction, no classes, ... and we use some "tricks"
to make it run fast -- we do have a pull request about extracting this
code to make it reusable but it was never merged because of performance
concerns). So, Twig would not adopt a PSR with interfaces to implement
output escaping.
For those interested, you can have a look at our implementation here:
https://github.com/twigphp/Twig/blob/1.x/lib/Twig/Extension/Core.php#L977
Moreover, I don't see how such a PSR would make projects more
interoperable. What problems are we trying to fix here?
Fabien
--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 php-fig+unsubscr...@googlegroups.com
<mailto:php-fig+unsubscr...@googlegroups.com>.
To post to this group, send email to php-fig@googlegroups.com
<mailto:php-fig@googlegroups.com>.
To view this discussion on the web visit
https://groups.google.com/d/msgid/php-fig/3df62d34-af9d-c6b3-5595-07fd246ac8a5%40garfieldtech.com
<https://groups.google.com/d/msgid/php-fig/3df62d34-af9d-c6b3-5595-07fd246ac8a5%40garfieldtech.com?utm_medium=email&utm_source=footer>.
For more options, visit https://groups.google.com/d/optout.
--
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 php-fig+unsubscr...@googlegroups.com.
To post to this group, send email to php-fig@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/php-fig/3c9fcdaf-1344-fe3d-47a8-abecf69fcaef%40gmail.com.
For more options, visit https://groups.google.com/d/optout.
