The end user won't have to deal with validation exceptions. It will be
wrapped in a sfForm object. You will have to catch exception only if you
use validators on their own (which will be quite rare).
Fabien
Matthias N. wrote:
> 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
-~----------~----~----~----~------~----~------~--~---
