Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:25765
Return-Path: <derick@php.net>
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Delivered-To: mailing list internals@lists.php.net
Received: (qmail 39822 invoked by uid 1010); 19 Sep 2006 21:26:24 -0000
Delivered-To: ezmlm-scan-internals@lists.php.net
Delivered-To: ezmlm-internals@lists.php.net
Received: (qmail 39807 invoked from network); 19 Sep 2006 21:26:24 -0000
Received: from unknown (HELO lists.php.net) (127.0.0.1)
  by localhost with SMTP; 19 Sep 2006 21:26:24 -0000
Authentication-Results: pb1.pair.com header.from=derick@php.net; sender-id=unknown
Authentication-Results: pb1.pair.com smtp.mail=derick@php.net; spf=permerror; sender-id=unknown
Received-SPF: error (pb1.pair.com: domain php.net from 82.94.239.5 cause and error)
X-PHP-List-Original-Sender: derick@php.net
X-Host-Fingerprint: 82.94.239.5 jdi.jdi-ict.nl Linux 2.5 (sometimes 2.4) (4)
Received: from [82.94.239.5] ([82.94.239.5:48398] helo=jdi.jdi-ict.nl)
	by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP
	id 22/8C-54096-F7060154 for <internals@lists.php.net>; Tue, 19 Sep 2006 17:26:24 -0400
Received: from localhost (localhost [127.0.0.1])
	by jdi.jdi-ict.nl (8.13.7/8.12.11) with ESMTP id k8JLQJFg000977;
	Tue, 19 Sep 2006 23:26:19 +0200
Date: Tue, 19 Sep 2006 23:26:10 +0200 (CEST)
X-X-Sender: derick@localhost
To: Pierre <pierre.php@gmail.com>
cc: Christian Schneider <cschneid@cschneid.com>, internals@lists.php.net,
        rasmus@php.net, ilia@prohost.org
In-Reply-To: <fe05d1540609160732u6087a59emdb97f949d3699479@mail.gmail.com>
Message-ID: <Pine.LNX.4.62.0609192324310.3563@localhost>
References: <20060916125431.42e9a5dd@pierre-u64> <450C02B3.10103@cschneid.com>
 <fe05d1540609160732u6087a59emdb97f949d3699479@mail.gmail.com>
X-Face: "L'&?Ah3MYF@FB4hU'XhNhLB]222(Lbr2Y@F:GE[OO;"F5p>qtFBl|yVVA&D{A(g3[C}mG:199P+5C'v.M/u@Z\![0b:Mv.[l6[uWl'
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Subject: Re: [PHP-DEV] Re: ext/filter, Final API proposal
From: derick@php.net (Derick Rethans)

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