Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:19994
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Message-ID: <4B.67.07637.41949734@pb1.pair.com>
To: internals@lists.php.net
Date: Mon, 14 Nov 2005 21:38:36 -0500
User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317)
MIME-Version: 1.0
References: <84.9C.07637.EEB48734@pb1.pair.com> <6A.CC.07637.49C48734@pb1.pair.com> <CC.51.07637.BDD58734@pb1.pair.com> <437932CE.80000@zend.com>
In-Reply-To: <437932CE.80000@zend.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-DEV] Re: results of the PHP6 wishlists
From: gamblergluck@yahoo.com (Roman Ivanov)

Antony Dovgal wrote:
> On 14.11.2005 12:55, Roman Ivanov wrote:
> 
>> wishlist> input filter extension (including some element of user 
>> wishlist> control)
>>
>> Will it be used _instead_ of $_POST and $_GET? 
> 
> 
> An extension instead of the arrays?
> You must be missing something...

I do not think so. If the only way to get 'post' and 'get' variables 
will be trough input_get(), then filter extension will effectively and 
functionally replace those arrays. Is it not righ?

>> Honestly, I'm not so sure it's a good idea to implement it like PECL 
>> extension does. Filtering individual variables is, in my opinion, a 
>> wrong way to treat user input.
> 
> 
> You may filter data recursively, so filtering, for example, _POST or 
> _GET would work fine.

Recursion does not solve the problem I'm trying to highlight.

//Way #1:
$filter = array(
     'name' => '/^[\w\d]+$/',
     'email' => RE_EMAIL,
     'wage'=> new IntFilter(5, 500),
     'phone'=>'/^\d{7,16}$/',
);
try {
     $input = filterInput($filter);
} catch (InvalidField $e) {
     user_error($e, E_USER_ERROR);
}

/*--------------------------------------------*/

//Way #2:
$name = input_get(INPUT_GET, 'name', FL_REGEXP, '/^[\w\d]+$/');
if ($name === NULL) {
     user_error("Invalid 'name' field", E_USER_ERROR);
}
$email= input_get(INPUT_GET, 'email', FL_EMAIL);
if ($name === NULL) {
     user_error("Invalid 'email' field", E_USER_ERROR);
}
$wage= input_get(INPUT_GET, 'wage', FL_INT, array('min_range' => 5, 
'max_range' => 500));
if ($wage === NULL) {
     user_error("Invalid 'wage' field", E_USER_ERROR);
}
$phone= input_get(INPUT_GET, 'phone', FL_REGEXP, '^\d{7,16}$');
if ($phone === NULL) {
     user_error("Invalid 'phone' field", E_USER_ERROR);
}

>> Besides, is it really necessary to make input filtering a part of the 
>> language?
> 
> 
> An extension is not a part of the language, you may or may not compile 
> it, while the language is still there.

"Part of the standard API, which is included with PHP and compiles by 
default", if you will.

>> It's a very high-level feature, and implementation may vary according 
>> to the needs of the developer. Plus, it's perfectly doable in pure PHP. 
> 
> 
> Yeah, that's why you can use your own callback for filtering.

Callback just plugs your function in some pre-defined structure.

>> In fact, I would go as far as removing session handling functions from 
>> the "core" language too. 
> 
> 
> You're late.
> Four or three years ago I'd agree with you, but it's too late for that.