Re: Re: RFC: Implementing a core anti-XSS escaping class

On 19/09/12 17:06, Michael Shadle wrote:

It feels like this is just using classes for the sake of using classes, adding an unnecessary layer of complexity (and discussion) for no real reason except that is the RFC authors preference.

+1 First the discussion was filtering vs escaping. Now it is about how to implement it as a class etc. I don't understand why people have any issue with it being a core procedural function. You can call that from your OO code just fine. Just like any other core procedural function. Yes, but typing the encoding every time is cumbersome. Or, if you don't want to set it every time, you'd have to set it globally. Then, you forgot to change it back somewhere when you're dealing with multiple encodings, and it all goes wrong.

There is no reason it has to be OO. OO has to call procedural functions already (string functions, array functions, curl, json, etc etc); but us procedural purists don't have to call OO methods and classes if we don't need to (except now some of the DateTime IIRC which bugs me :p) Anyway how hard is it to use something akin to the filter functions? That's what constants/flags are for. Call it str_escape(string, flags optional, encoding optional) and be done with it. Since it won't be useful to have escape_var or escape_input type of differentiation and this seems like it could just fit under the string family of functions (I am a fan of namespaced functions by prefix) After that it seems like the discussion would be: 1) do we even need encoding or is UTF8 just fine UTF8-only is certainly not just fine.

2) what are the flags to be defined for different escaping methods $.02

-- Andrew Faulds http://ajf.me/