getParam should, imho, return params only, if theres need for routing for
cacaded stuff then maybe a getInput or similar. You shouldn't be able to
override post data with a param, or, at least thats not how the fw should be
recommending apps be built using getParam like $_REQUEST.
If you get rid of the $_request-like way of getParam, then the validation
question of origin becomes less problematic. Anyone using getParams etc
should already be validating the type of data (as it's from userland) with
Zend_Validate/Zend_Filter, and/or putting a regexp on the route.
However, my response was in response to
That's fine, just as long as new users always use $_POST or getPost() to
retrieve POST variables so they know where they are coming from.
If you change getParams, this problem goes away completely.
Kevin
----- Original Message -----
From: "Matthew Weier O'Phinney" <[EMAIL PROTECTED]>
To: <[email protected]>
Sent: Thursday, March 22, 2007 10:59 AM
Subject: Re: [fw-general] Zend_Filter_Input...
-- Kevin McArthur <[EMAIL PROTECTED]> wrote
(on Thursday, 22 March 2007, 11:36 AM -0700):
Hopefully getParam will be unified with the rest of the get* methods in
Zend_Request, and this all wont be a problem.
I fail to see how this is even related to the discussion. The request
you had earlier this week was to have getParam(null) return the entire
list of params, vs. having a getParams() method -- what does this have
to do with input filtering?
Additionally, getParam() right now looks through several arrays:
* internal param store (usu. set by the router from the request uri)
* $_GET params
* $_POST params
The reason for this is that information necessary for routing can be
found in each of these, and if not found in one should cascade down
through the others until found (if available).
Note: getUserParam()/getUserParams() return just the internal param
store.
To normalize the API, I will definitely consider modifying getParam()
and getUserParam() to accept a null argument to return the entire
arrays, and then remove getParams() and getUserParams(). But I'm not
sure that these changes address the input filtering discussion.
----- Original Message -----
From: "Simon R Jones" <[EMAIL PROTECTED]>
To: <[email protected]>
Sent: Thursday, March 22, 2007 10:34 AM
Subject: RE: [fw-general] Zend_Filter_Input...
> > It was never intended as a general-purpose object for
> > input filtering -- that's a goal for a later iteration, which will
> > still
> > need to account for the variety of sources when dealing with routing.
>
> That's fine, just as long as new users always use $_POST or getPost()
> to
> retrieve POST variables so they know where they are coming from.
>
> Just something that may be worth highlighting in the manual for 1.0 -
> Presumably there will be/is a small section saying where to get various
> things when using the Router (i.e. URL parameters, GET vars, POST
> vars)?
--
Matthew Weier O'Phinney
PHP Developer | [EMAIL PROTECTED]
Zend - The PHP Company | http://www.zend.com/
