On Tue, 19 Sep 2006, Pierre wrote:
> On 9/19/06, Derick Rethans <[EMAIL PROTECTED]> wrote:
> > On Sat, 16 Sep 2006, Pierre wrote:
> >
> > > 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.
>
> There is no other choices. Unless we add naming argument in php 5.2,
> we are out of choicses. I also not think a function with five
> arguments and one of them being mixed is a good thing, it is what we
> did in the early versions of php, it was and is a mistake.
Well, you're still doing the same, but now with the parameter that also
contains the filter. This is fundamentally different compared to the
previous API, because both the flags and the options *modify* a filter,
and both of them are not required.
When I was first implementing this stuff I thought that it was
best to always use an array to specify both options and flags as 4th
parameter. However, there is only one filter (validate_int) that
currently uses the options (min_range and max_range); and I found that
having to use an array for all other filters just because of
validate_int was a bad idea, as it unnecessarily bloats calling
filters with funky array() syntax. Hence the status quo where you only
have to use an array if you want to use options besides flags at well.
> > 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 );
>
> And you have to use an array if you have options, add a fifth argument
> for the upcoming charset, and a sixth if we need another one? That's
> insane and confusing, sorry.
Which sixth parameter? And no, it's not more confusing then having to
use an array as third parameter *only* in case you want flags and or
options. As I said before: the filter is one part of the call, and the
filter's modifiers (options/flags) are. They don't logically belong
together in one parameter.
> > 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).
>
> It is consistent. All function works the same way. The same definition
> works for both filter_get and filter_get_args.
Actually, it's less consistent *and* it would require another parameter
to the functions, while you just suggested that you disliked more
parameters. Again, it's also fundamentally two different things:
- request input data
- existing variables
Therefore there should be two sets of functions, one of the classes with
both a single filter specification and one with a filter specification
array.
So this boils down to the following proposal:
/**
* Returns the specified $variableName from the request input source
* $source filtered through the filter specified with $filterId.
* Filter modifiers can be passed in $filterOptions.
*
* @param int $source (INPUT_GET...)
* @param string $variableName
* @param int $filterId
* @param mixed $filterOptions Integer with flags, or array with two
* elements: "flags" an "options".
* @return mixed
*/
input_get( $source, $variableName, $filterId [ , $filterOptions ] );
/**
* Returns an array acording to the $varSpecs from the request input
* source $source filtered through the filter specified in the 'filter'
* array element of $varSpecs. Filter modifiers can be passed in the
* 'flags' and 'options' array members. (The elements in $varSpecs are
* *always* arrays and not a single filterId).
*
* @param int $source (INPUT_GET...)
* @param array(string=>array) $varSpecs
* @return mixed
*/
input_get_args( $source, $varSpecs );
/**
* Returns the specified $variable filtered through the filter specified
* with $filterId. Filter modifiers can be passed in $filterOptions.
*
* @param mixed $variable
* @param int $filterId
* @param mixed $filterOptions Integer with flags, or array with two
* elements: "flags" an "options".
* @return mixed
*/
input_filter_var( $variable, $filterId [ , $filterOptions ] );
/**
* Returns an array with variables according to the $varSpecs. Each of
* the array members of $data is filtered through the filter specified
* in the 'filter' array element of $varSpecs. Filter modifiers can be
* passed in the 'flags' and 'options' array members. (The elements in
* $varSpecs are *always* arrays and not a single filterId).
*
* @param array(mixed) $variable
* @param array(string=>array) $varSpecs
* @return array(mixed)
*/
input_filter_args( $variableArray, $varSpecs );
/**
* Returns whether the variable $varName is available in the source
* $source.
*
* @param int $source (INPUT_GET...)
* @param string $varName
*/
input_has_variable( $source, $varName );
/**
* Returns the filter ID belonging to the filter with the name
* $filterName.
*
* @param string $filterName
* @return int
*/
input_get_filter_id( $filterName )
/**
* Returns an array of all filters, where the key is the filter ID and
* the value the filter name.
*
* @return array(int=>string)
*/
input_filters_list();
>From the mail about how FLAG_ARRAY should work:
On Tue, 19 Sep 2006, Pierre wrote:
> On 9/19/06, Derick Rethans <[EMAIL PROTECTED]> wrote:
> > 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.
>
> The flag allows arrays and always returns an array. It is obvious
No it isn't obvious at all. Look at this example:
<?php
$varSpecs = array(
'varName' => array( 'filter' => 'string', 'flags' => FILTER_FLAG_ARRAY )
);
$data = array( 'varName' => 42 );
$filteredData = input_filter_args( $data, $varSpecs );
?>
Because the variable 'varName' has the FILTER_FLAG_ARRAY you say that it
should make an array out of this, resulting in the data:
$filterData = array( 'varName' => array( 42 ) );
Unless you want to ignore this flag for filtering already existing
variables which makes things inconsistent again.
Therefore we should use use the FILTER_FLAG_ARRAY to recursively go over
the input variable that is being filtered. If the flag is not there and
the input variable is an array, it should return false/null (whatever
the default is).
regards,
Derick
--
Derick Rethans
http://derickrethans.nl | http://ez.no | http://xdebug.org
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
