Re: ext/filter, Final API proposal

On Sat, 16 Sep 2006, Pierre wrote: > Hello, > > Given the recent discussion about the filter API in the pecl-dev list > (http://news.php.net/php.pecl.dev/4123), I summarize again what I > proposed a while back. It is very important to agree on an API now or > we will have to remove filter from 5.2.0. > > This proposal does not reflect what we have now in CVS. > > The major changes are: > - drop filter_data, input_get will use INPUT_DATA just like > input_get_args > > - input_get accepts takes no option or flag by default, only the filter > type. If you need options or flags, you pass them and the filter type > as array. Consistent and flexible. I think that is a bad idea, and it's also something I disliked in the _get_args() implementation as we'd basically be overloading the parameter then. I would not want that for input_get(), and I think we should also come up with something else for the definition in input_get_args() there as well. > Please reply as soon as possible (yes, many of us are on their way > home :). Also I ask you to focus on the API itself, not on a missing > filter type, option or flag. Such things can be added anytime after > 5.2.0. > > Proposal: > ********** > > I. Availalbe functions: > ------------------- > > * input_get > Gets variable from outside PHP or from a userland variable and > optionally filters it using one filter and its options or flags. It > accepts only scalar by default, array can be returned using > ALLOW_ARRAY. > > * input_get_args > Gets multiple variables from outside PHP or from a userland variable > and optionally filters them using different filters and options/flags. > It accepts only scalar by default, array can be returned using > ALLOW_ARRAY. > > * input_has_variable > Checks if variable of specified type exists. > > * input_name_to_filter > Returns the filter ID belonging to a named filter > > * input_ filters_ list > Returns a list of all supported filters Without the spaces I hope :) > > II input_get usages > > II.1 without options or flags > > ?mystring=<b>bold</b> > input_get(INPUT_POST, 'mystring', FILTER_SANITIZE_SPECIAL_CHARS); > > ?myint=493 > input_get(INPUT_GET, 'myint', FILTER_VALIDATE_INT); > > Using a user variable: $userint = 493; > input_get(INPUT_DATA, $userint, FILTER_VALIDATE_INT); > > > II.2 with options or flags > > /*mystring=<b>bold</b>*/ > input_get(INPUT_GET, 'mystring', array( > 'filter' =>FILTER_SANITIZE_STRING, > 'flags' => FILTER_FLAG_ENCODE_HIGH > |FILTER_FLAG_ENCODE_LOW > ) > ); I think we should just stick to the old syntax here: input_get(INPUT_GET, 'mystring', FILTER_SANITIZE_STRING, FILTER_FLAG_ENCODE_HIGH|FILTER_FLAG_ENCODE_LOW ); [snip two examples] In that case INPUT_DATA becomes ugly so I prefer a different function for filtering already existing data in variables (as you're not getting any input as "input_get" refers to). [snip III. input_get_args (require array as arguments)] regards, Derick