Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:25766
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain php.net from 82.94.239.5 cause and error)
Date: Tue, 19 Sep 2006 23:26:13 +0200 (CEST)
To: Pierre <pierre.php@gmail.com>
cc: internals@lists.php.net, rasmus@php.net, ilia@prohost.org
In-Reply-To: <20060916125431.42e9a5dd@pierre-u64>
Message-ID: <Pine.LNX.4.62.0609192317250.3563@localhost>
References: <20060916125431.42e9a5dd@pierre-u64>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Subject: Re: [PHP-DEV] ext/filter, Final API proposal
From: derick@php.net (Derick Rethans)

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