Re: Re: ext/filter, Final API proposal

On Sat, 16 Sep 2006, Pierre wrote: > On 9/16/06, Christian Schneider <cschneid@cschneid.com> wrote: > > Pierre wrote: > > > 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. > > > > Looks good. > > > > > * 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. > > > > The current documentation page shows an example where all return values > > are an array: > > array(6) { > > ["product_id"]=> > > array(1) { > > [0]=> > > string(17) "libgd%3Cscript%3E" > > } > > ... > > > > I would prefer if it would return > > array(6) { > > ["product_id"]=> > > string(17) "libgd%3Cscript%3E" > > ... > > unless FILTER_FLAG_ARRAY is given in which case it should behave like > > before. This would make it easier to use the filtered values IMHO. > > It always returns an array when FILTER_FLAG_ARRAY is given. Even when > the input value was a scalar. It spares yet another is_array/isset > test. And it accepts only scalar by default or when FILTER_FLAG_SCALAR > is given. I would not expect that... I thought the FLAG would just mean that it would iterate over a whole array and allow it. I think that we should add a second flag called "FORCE_ARRAY" or something instead. > > > > > > II input_get > > > II.1 without options or flags > > > > > > ?mystring=<b>bold</b> > > > input_get(INPUT_POST, 'mystring', FILTER_SANITIZE_SPECIAL_CHARS); > > > > The documentation mentions 99 as $_REQUEST for input type right now. I'd > > prefer to be able to say INPUT_GET | INPUT_POST to get values from a > > combination of sources. Or at least have INPUT_REQUEST as constant > > definition instead of 99. > > It uses INPUT_REQUEST (which is not yet implemented, and will not be > for 5.2.0). One should rely only on the constants not their values :) Right... INPUT_REQUEST is better than doing INPUT_GET | INPUT_POST in my opinion. regards, Derick