> 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