For me it is important that the result is very similar as with symfony
1.0: The validation manager must be able to validate ALL fields and
must not stop (throw exceptions or whatever) at the first problem. And
I want to have an easy way/helper to get to the results of a certain
field (like the good old form_error() helper)
IMHO the results of the various validators are only meta information
to give the user context information what is wrong. Isn't it enough to
throw one single exception if any of the validators (thus the complete
validation) failed at the end of validation so we can check if a form
or whatever was validated successfully or not?
How would the exception handling look like for when we have exceptions
for each validator to achive a similar simple behaviour like with good
old sf 1.0 ? In short: If I (as end user of the validation system)
don't have to care about validation exception handling that much.. so
ok.. let's use exceptions.. ;-)
Regards,
Matthias
On 1 Okt., 22:29, "Matthias N." <[EMAIL PROTECTED]>
wrote:
> IMHO you should rather put your energy into other things - I never
> thought that the validation system is the problem. ;-)
>
> Using exceptions for that feels like overkill to me..
>
> Introduction of error codes might be useful.. but I think there are
> other things that need to get polished.
>
> Would be much more interesting to here a bit more about the whole
> thing - what you are going to change, for example how the new helpers
> will look like. ;-)
>
> Regards,
> Matthias
>
> On 30 Sep., 20:59, Fabien POTENCIER <[EMAIL PROTECTED]>
> wrote:
>
> > Hi all,
>
> > I'm working on the new validation system and I want your thoughts about
> > a design decision I have to take.
>
> > Let's take a string validator:
>
> > $v = new sfValidatorString(array('max_length' => 2));
>
> > Then let's try to validate a string:
>
> > $ret = $v->validate('t');
>
> > Here, $ret is 't'.
>
> > Now, if I do:
>
> > $ret = $v->validate('foo');
>
> > What happens?
>
> > 1 - The validator throws a sfValidatorException:
>
> > throw new sfValidatorException('String is too long');
>
> > 2 - The validator returns a sfValidatorError object:
>
> > return new sfValidatorError('String is too long');
>
> > 3 - The validator returns false or another "magic" value:
>
> > return false;
>
> > 3 is not very good because then I can't return false as a valid value
> > (same goes for null or whatever other value).
>
> > My preference goes to the exception but PHP exceptions are quite
> > inflexible, the message has to be a string, so if I want to return
> > several error messages, I can't:
>
> > throw new sfValidatorException(array('String is too long', 'foo is
> > not a valid string'));
>
> > Here is a typical usage:
>
> > try
> > {
> > $ret = $v->validate('foo');}
>
> > catch (sfValidatorException $e)
> > {
> > // do something with the error
>
> > }
>
> > The sfValidatorError usage looks good but the user code looks less "clean":
>
> > $ret = $v->validate('foo');
> > if ($ret instanceof sfValidatorError)
> > {
> > // do something with the error
>
> > }
>
> > It's less clean because if you forget to check the return value, you can
> > have some weird behaviors in your code and debugging can then be much
> > harder.
>
> > Thanks for your ideas,
> > Fabien
--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---
