in my opinion a more implicit api would fit better here
so instead of
$request->getParameterAsInt('foo', 'bar');
only e.g.
$request->getParameter('foo', 'bar', 'int');
On 7 Jul., 10:27, "Tristan Rivoallan" <[EMAIL PROTECTED]>
wrote:
> 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 Rivoallanhttp://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
-~----------~----~----~----~------~----~------~--~---
