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
-~----------~----~----~----~------~----~------~--~---
