Re: [RFC] Escaping RFC for PHP Core - Updates?
| From: | Pierre Joye | Date: | Sat, 07 Sep 2013 08:51:03 +0000 |
| Subject: | Re: [RFC] Escaping RFC for PHP Core - Updates? | ||
| References: | 1 2 3 | Groups: | php.internals |
| Request: | Send a blank email to internals+get-68940@lists.php.net to get a copy of this message | ||
Hi,
On Sep 7, 2013 10:35 AM, "Yasuo Ohgaki" <yohgaki@ohgaki.net> wrote:
>
> Hi Leigh,
>
> On Sat, Sep 7, 2013 at 2:56 PM, Leigh <leight@gmail.com> wrote:
>
> > Looks like the rfc author was unable to implement it himself at the time
> > of the proposal.
> >
> > The last thing in the discussion thread looks like "implement it in PECL
> > first, and it might get bundled later"
> >
> >
> > http://marc.info/?l=php-internals&m=134822086426610&w=2
> >
> Thank you for the info. I searched my mailbox, but I couldn't find this.
>
> It would be better to implement this as SPL_Escape class.
>
> SPL_Escape::jsString()
> SPL_Escape::phpString()
> SPL_Escape::html()
> SPL_Escape::htmlAttribute()
> etc
>
> It looks nicer than Escaper::escapeJs(), Escaper::escapeHtml(), etc.
>
> Any comments?
> Anyone mind if I edit the RFC?
I like the goal of this proposal.
It would however fits much better in ext/filter. Yes, escaping has
different purposes than filtering.
I have some worries about the implementation. It is not an easy task and
some external libraries may already have these features (esp. CSS or JS).
About the API:
To have a kind of wrapper class is not very useful. It will most likely end
with static methods with a large set of arguments or options array, not
very sexy.
Cheers,
Pierre