> From: Perrin Harkins [mailto:[EMAIL PROTECTED]]
> Sent: 07 June 2002 18:05
> For example, if you have a form for registering as a user which has
> multiple fields, you want to be able to tell them everything that was
> wrong with their input (zip code invalid, phone number invalid, etc.),
> not just the first thing you encountered.
> Putting that into a model object is awkward, since coding your
> constructor or setter methods to keep going after they've found the
> first error feels wrong. You can write a special validate_input()
> method for it which takes all the input and checks it at once
returning
> a list of errors. You could also just punt and push this out to the
> controller. (Not very "pure" but simple to implement.) Either way
you
> can use one of the convenient form validation packages on CPAN.
When collecting multiple values for a single model, there generally is
both individual field validation, and an overall validation check. I
work in financial applications - often, there are inter-field
dependencies where validity cannot be determined until some decision has
been made, or some other detail gathered. As a general rule, there will
_always_ be a point in time after all details have been gathered, where
the Model must ask itself, 'Am I complete and integral?'.
What I am saying, is that you can't get around it! At some point in
time, you have to ask 'Are you OK, honey?'
There are a number of obvious stategies for dealing with this.
Some folks like to pass it all to the constructor, and get it over with
during the pangs of birth. Sometimes when this happens, instantiation
will fail, and you end up hanging your error information at a class
level ala DBD/DBI. Others don't mind instantiating an invalid Model, to
hold details of what went wrong (argh!). Some smarties pass an Exception
object into the instantiation, that collects all the exceptional detail
on the way, leaving the Controller at least with an instance handle on
what when badly wrong.
An alternative approach is to instantiate a mini-me Model without much
going on, and then to iterate through assigning properties or calling
methods and reaping any exceptions along the way into a collection for
later user castigation. Such mini-me Modellers must always remember to
ask the 'Was that good for you, Honey?' question at the end, or they end
up in purgetory, and have to bring home flowers!
Another intereting introspection is: Should I let the default View deal
with the errors, or should I have an Error View?
And the answer is... well, I guess it depends on your bent.
For finicky field errors, it feels natural that the default View should
indicate problems where they occurred [ala stars next to the required
fields, or little digs at the users, next to the offending erroneous
zone.
For major whamoo! if ( not defined $universe ) big bangs, it may be
better to redirect to a safer plane. If this is the case, the Controller
must be able to grok the exception and redirect as appropriate.
All in all, I think prefer a Controller something like this:
my $Exeption = My::Exception->new();
my $params = cleanupParams( $r );
my $Model = My::Model->new( %$params, exception => $Exception, );
my $View;
if ( $Exception->had_Fatal() or not defined $Model ) {
$View = My::ErrorView->new( exception => $Exception, model => $Model
);
} else {
$View = My::View->new( exception => $Exception, model => $Model );
}
print $View if $View;
print STDERR $Exception if $Exception->had_Any();
£0.04,
Regards
Jeff
