On Mon, Jul 7, 2008 at 10:11 AM, Fabian Lange
<[EMAIL PROTECTED]> wrote:
> I fear that we are over-engineering here.
> What shall the input filtering bring value for the developer. Or again my
> beloved question: What use cases shall it support.
> I think in this thread already some very esotheric options were discussed
> (liked octal values)
i added the octal values optio just to show how advanced ext/filter
flags could be used. a common use case would be :
$request->getParameter('foo', 'bar', new sfInputFilterInteger());
do you find this overengineered ?
if so, this would do the trick :
$request->getParameterAsInt('foo', 'bar');
> And for a first implementation we really should follow a 80/20 rule.
definitely. I think that the code above fills the 80 part, while the
underlying sfInputFilter class (allowing advanced ext/filter flags
usage) would fill the remaining 20.
> Event dispatching sounds like a good solution.
this is unclear to me. where will the developer define its filtering
strategies ? specific classes ? how will they be associated to the
actions, tasks, etc ?
++
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
-~----------~----~----~----~------~----~------~--~---