Hi all,
I added my proposal for input filtering once ago in a ticket: http://trac.symfony-project.org/ticket/1201 The basic solution is not to have the method sfRequest::getParameter(), but sfRequest::getInt(), sfRequest::getBool(), sfRequest::getArray(), sfRequest::getString(), sfRequest::getRawString() and sfRequest::getFloat() - thus, one method per basic data type. I actually still like this version best as it's the most simple to use. I don't see any advantage in filtering octal or hexadecimal numbers. I just want to make sure it's an integer, everything else is irrelevant really (for GET parameters - may be different for POST parameters). The important thing for me is that the syntax is actually easy and slick to use. Every simple action takes one or more parameters, and I don't want to spend 10 lines of code every time just to retrieve these parameters. Bernhard On Sat, Jul 5, 2008 at 12:25 AM, Francois Zaninotto <[EMAIL PROTECTED]> wrote: > > Tristan, > > No matter how powerful and well designed (on an OO point of view) the > input filtering is, its API must be KISS and DRY. To my mind that > excludes the second and the third solution, which require so much code > that they will probably not be used in the majority of cases. > > But the first solution is not ideal either. If it fits simple cases, > how about repetitive ones? > > One suggestion could be to have an `input.yml` in all modules, just > like we have a `view.yml` - and with the same inheritance mechanism. > This file would declare automated filtering on certain parameters on a > per-action (and per-method) basis, such as: > > # in apps/frontend/modules/article > getList: > page: > type: int > options: > min_range: 5 > flags: FILTER_FLAG_ALLOW_OCTAL | FILTER_FLAG_ALLOW_HEX > > getArticle: > id: > type: int > options: > min_range: 5 > flags: FILTER_FLAG_ALLOW_OCTAL | FILTER_FLAG_ALLOW_HEX > > postArticle: > id: > type: int > options: > min_range: 5 > flags: FILTER_FLAG_ALLOW_OCTAL | FILTER_FLAG_ALLOW_HEX > title: > type: string > body: > type: string > > Now, of course, we could use the existing YAML precedence, and the > listing above could also be written: > > # in apps/frontend/modules/article > all: > id: > type: int > options: > min_range: 5 > flags: FILTER_FLAG_ALLOW_OCTAL | FILTER_FLAG_ALLOW_HEX > > getList: > page: > type: int > options: > min_range: 5 > flags: FILTER_FLAG_ALLOW_OCTAL | FILTER_FLAG_ALLOW_HEX > > postArticle: > title: > type: string > body: > type: string > > We could also define named filters, as there are named validators, to > be reused throughout the application, still in YAML: > > # in apps/frontend/modules/article > _filters: > integer: > type: int > options: > min_range: 5 > flags: FILTER_FLAG_ALLOW_OCTAL | FILTER_FLAG_ALLOW_HEX > > getList: > page: integer > > postArticle: > title: > type: string > body: > type: string > > That's just a rough idea, and I know how some of the devs hate YAML, > but it has some advantages. And it doesn't prevent you from writing a > totally OO API 'à la Zend' that people can use if the YAML file don't > fit their needs. > > Just my 2c. > > François > > 2008/7/4 Tristan Rivoallan <[EMAIL PROTECTED]>: >> >> hi, >> >> as you may know, i'm responsible for implementing input filtering in >> the forthcoming symfony-1.2. >> >> before starting to code anything, i would like to get some community >> feedback about the different solutions i've came up with : >> >> (in any case, the underlying filtering framework will be ext/filter[1]) >> >> * first solution : extend the sfRequest::getParameter() semantics, >> adding a simple ext/filter wrapper. eg. : >> >> // Signature >> public function getParameter($name, $default_value, $filter_name, >> array $filter_options) >> >> // Usage >> $request->getParameter('foo', 'bar', FILTER_VALIDATE_INT, >> array('min_range' => 5, 'max_range' => 10, 'flags' => >> FILTER_FLAG_ALLOW_OCTAL | FILTER_FLAG_ALLOW_HEX)); >> >> * second solution : extend the sfRequest::getParameter() semantics, >> abstracting the filtering logic. eg. : >> >> // Signature >> public function getParameter($name, $default_value, sfInputFilter >> $filter_instance) >> >> // Usage >> $request->getParameter('foo', 'bar', new >> sfExtFilterInputFilter(array('id' => FILTER_VALIDATE_INT, 'options' => >> array('min_range' => 5, 'max_range' => 10, 'flags' => >> FILTER_FLAG_ALLOW_OCTAL | FILTER_FLAG_ALLOW_HEX))); >> >> * third solution : implement a complete input filtering framework >> similar to what can be found in the zend framework[2] >> * fourth solution : something better that i've not thought about :) >> >> looking forward to your insights. >> >> ++ >> tristan >> >> [1] http://php.net/filter >> [2] http://framework.zend.com/manual/en/zend.filter.input.html >> >> -- >> Tristan Rivoallan >> http://www.clever-age.com >> Clever Age - conseil en architecture technique >> GSM: +33 6 219 219 33 Tél: +33 1 53 34 66 10 >> >> > >> > > > > --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "symfony developers" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/symfony-devs?hl=en -~----------~----~----~----~------~----~------~--~---
