+1 for using the event dispatcher here. That should make for a very
elegant backend.
Integration with the sfForm validation system is going to be tricky,
considering the requirement they be decoupled... perhaps the
sfValidation system could be decoupled itself and be disabled when
input filtering is being used? Or does the validation system in sfForm
go beyond what input filtering does? (i.e. sfValidatorPropelUnique
would not be replicated in the input filtering layer)
- Kris
On Jul 6, 7:31 pm, Dustin Whittle <[EMAIL PROTECTED]>
wrote:
> All,
>
>
>
>
>
> >> 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.
>
> +1 from me. I think we should listen to request.filter_parameters event, and
> create an option for changing the default filtering strategy.
>
>
>
> >> 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.
>
> I think we should drop the ext as it is php core for 5.2. For #1201, I think
> it is simpler to make the third argument of request->getParameter optional
> and allow a constant or object:
>
> $request->getParameter('foo', 'default', FILTER_SANITIZE_STRIPPED);
>
> $request->getParameter('foo', 'default', FILTER_UNSAFE_RAW);
>
> $request->getParameter('foo', 'default', new
> sfStrippedInputFilter(array('min' =>5, 'max' => 10, 'allow_hex' => true,
> 'allow_octal' => true));
>
> $request->getParameter('foo', 'default', new sfStringInputFilter(array('min'
> =>5, 'max' => 10));
>
> Any ideas on how to integrate with the validation system? There seems to be
> some duplication, defining min/max, etc.
>
> - Dustin
>
>
>
> >> Also, once something is filtered, it should be cached, maybe a
> >> sfNamespacedParameterHolder is appropriate?
>
> > indeed.
>
> > ++
> > tristan
--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---
