Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:94689
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain thomasbley.de from 85.13.128.151 cause and error)
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 8bit
User-Agent: ALL-INKL Webmail 2.11
In-Reply-To: <d6dc43cc-53a9-1285-0331-2a6d51b70b6e@gmail.com>
References: <20160724170644.916231A8060C@dd1730.kasserver.com> <fee7cd80-0da9-6c92-0783-1d6f54ecaa17@gmail.com> <20160724180950.E1D6B1A8066E@dd1730.kasserver.com><d6dc43cc-53a9-1285-0331-2a6d51b70b6e@gmail.com>
To: internals@lists.php.net, rowan.collins@gmail.com
Message-ID: <20160724195741.BE1CF1A8066E@dd1730.kasserver.com>
Date: Sun, 24 Jul 2016 21:57:41 +0200 (CEST)
Subject: Re: [PHP-DEV] [RFC] New operator for context-dependent escaping
From: mails@thomasbley.de ("Thomas Bley")

> Frameworks are free to write all sorts of weird shit:

with set_escape_handler(), the "weird shit" is in one place and can be quickly verified. Now the "weird shit" is spread over all templates.
Normally the problem is not fixing the frameworks, it's most work to fix code that is using the frameworks in a wrong way.

Regards
Thomas



Rowan Collins wrote on 24.07.2016 20:29:

> On 24/07/2016 19:09, Thomas Bley wrote:
>>> Then why is absolutely everything in the current RFC optional and
>>> configurable to the Nth degree?
>> It's one handler: set_escape_handler() (N=1)
>>
>> Currently, every framework has it's own methods for escaping. To get this
>> together, set_escape_handler() is a good choice, similar to
>> set_error_handler().
> 
> It's not set_escape_handler() that I'm concerned about, it's how you 
> actually use it in the templates. At the moment, the only thing the RFC 
> actually asserts about the escape handler is "it's a function with two 
> arguments". Frameworks are free to write all sorts of weird shit:
> 
> <?* $foo, 'html' ?>
> <?* 'html', $foo ?>
> <?* $foo, 'text/html' ?>
> <?* $foo, [$this, 'escaper'] ?>
> <?* $foo, $this ?>
> <?* $foo, 'js | html' ?>
> <?* $foo, 'js + html' ?>
> <?* $foo, ['js', 'html'] ?>
> <?* $foo, '[js, html]' ?>
> <?* $foo, '{js, html}' ?>
> <?* $foo, 'html(UTF-8)' ?>
> <?* $foo, 'UTF-8' ?>
> <?* [$foo, $bar, $baz], 'ul > li' ?>
> etc
> etc
> 
> If you want to provide something that will be the same in all 
> frameworks, then you've got to actually provide it.
> 
> 
>>> OK, so I can dynamically redefine the same syntax to mean different
>>> things at different times, within the same application. I'm not entirely
>>> sure that's a particularly good thing.
>> It's the same thing with set_error_handler(), set_exception_handler(),
>> spl_autoload_register(), error_reporting(), etc., this concept is proven to
>> work.
> 
> OK, fair enough. I'm not sure it's really a killer feature, though. The 
> fact that I can't easily redefine "function e()" is no more of a problem 
> here than anywhere else in the language.
> 
> 
>>> In my opinion, they are central to the feature, not an optional extra.
>> maybe you can join the rfc and provide the implementation?
> 
> The implementation I'm talking about is hardly complex, just some 
> default arguments to htmlspecialchars(). Or that would be the case, if 
> we didn't need to provide one escape callback to handle all possible 
> arguments, rather than registering for a specific strategy name.
> 
> Regards,
> 
> -- 
> Rowan Collins
> [IMSoP]
> 
> 
> -- 
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>