On Mon, Oct 15, 2012 at 1:29 PM, sergio_101 <
[hidden email]> wrote:
>> For implementation just use good ol'e exception handling in select
>> places (usually pretty high up). That leaves the vast majority of the
>> code clean and unburdened by exception-handling/validation code.
>
> i am not sure i follow...
>
> do you mean.. have a model throw an exception if validity is not met?
It depends on what you mean by "validity". To me, just saving the
object to be worked on later should not present any validation errors.
Something can only be "invalid" at the point it is attempted to be
*consumed* by the domain for actual processing, but can't be. Until
then, no worries about validity should be expressed by the app or the
code.
That's what I was trying to convey by my example about validating when
a field merely loses focus. That field is not needing to be consumed
yet, so doing it merely by losing focus is too eager. It should be
done only just before it is absolutely needed, for example, when the
form is submitted.
Exception handling is one way, but sometimes user-entries need to be
pre-validated up-front and so a direct approach is fine there too
(e.g., #validationErrors could return a collection of problems which,
if empty, indicates no errors).
_______________________________________________
seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside
Locked
