hi,
On Sat, Jul 5, 2008 at 10:44 AM, Dustin Whittle
<[EMAIL PROTECTED]> wrote:
> I think the larger problem breaks down into three pieces:
>
> Input Filter Framework
> Input/Form Validation Framework
> Output Escaping Framework
>
> Each piece should follow the symfony platform standards: OOP,
> separation/independent, flexible/extendable, easy to implement, and fast.
>
> +1 for creating a complete OOP interface to ext/filter similar to Zend.
in that case, why not use zend's api ? it's already complete, clear,
documented and unit tested. But it's a very verbose api, and we should
provide integration means. eg. :
// Define filters
$filters = array(
'month' => array(
'Digits', // filter name at integer index [0]
'fields' => 'mo' // field name at string index ['fields']
)
);
// Define validators
$validators = array(
'password' => array(
'StringEquals',
'fields' => array('password1', 'password2')
)
);
// Other filtering options
$options = array('escapeFilter' => 'StringTrim');
// Setup input filtering
$request->setupInputFiltering($filters, $validators, $options);
All this code could be automatically setup using some input.yml file,
as françois suggested.
> I think the mvc framework should provide an easy interface to combine these
> sub-frameworks ensuring its easy to use and follow DRY/KISS. I do not think
> yaml is the answer, but we should ultimately try to build a simple/reusable
> api. If someone wants to write an adapter that makes it simple with yaml,
> than why not.
+1 with that, i do not think that yaml should be part of the core
filtering framework, but it could be nice to add it in a second
iteration.
> I think we should expose the filter methods via the getRequestParameter to
> make it easy for simple cases, yet use sfInputFilter instances for complex
> ones.
One way to do this is to build on the second solution (extended
::getParameter() semantics + filtering abstraction) with adding up
some abstraction. We can provide users with utility filtering classes.
eg :
// Signature
public function getParameter($name, $default_value, sfInputFilter
$filter_instance)
// Usage
$request->getParameter('foo', 'bar', new
sfExtFilterIntegerInputFilter(array('min' =>5, 'max' => 10,
'allow_hex' => true, 'allow_octal' => true)));
Pros :
• not too verbose (and keep in mind that most people will only need to
use "$request->getParameter('foo', 'bar', new
sfExtFilterIntegerInputFilter());")
• developers who want to can use the underlying sfExtFilterInputFilter
class for complete ext/filter features access
• very easy to implement new filters : myProjectISBNInputFilter, etc
• mostly independent from symfony
• can serve as a basis for building a yaml adapter
Cons :
• i'm sure you'll have much to say :)
to make it even simpler, we can also expose new sfRequest methods, as
described by bernhard in ticket #1201.
> Also, once something is filtered, it should be cached, maybe a
> sfNamespacedParameterHolder is appropriate?
indeed.
++
tristan
--
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
-~----------~----~----~----~------~----~------~--~---
