Hey Perrin & Bill --

> You could also just punt and push this out to the 
> controller.  (Not very "pure" but simple to implement.)  

This is exactly what I had in mind.  (Perhaps you can explain what you mean
by "not very pure".)  The methods in any model module I would write would
have expectations that input is already valid.  Invalid input to a model
method should throw an exception of some sort (maybe die() -- but something
clearly documented in POD, whatever it is).  The purpose of the controller
is to validate input and construct valid arguments into these model methods.

The controller is also responsible for catching any exception from the
methods it calls (model methods, Perl core methods, other module methods --
they're ALL the same!), and relaying that to the output view in a reasonable
fashion.  By reasonable I do *not* mean "pretty HTML".  A "500 Internal
Server Error" is perfectly reasonable in some situations.

This fits into my general feeling that the role of the controller is to
interface between the UI and the model.  As I said in my first message on
the topic, the model should be thought of in the context of being used from
a variety of interfaces besides the web ("cron", for instance).  A
"controller" between a cron process and your model, for example, would be
responsible for ensuring that valid arguments are passed into the model
methods and that errors are thrown back to cron in such a way that cron can
do something useful with them (such as invoke "Vixie" cron's capability to
email the process owner).


> Either way you 
> can use one of the convenient form validation packages on CPAN.

The members of the CGI::Application mailing list seem particularly fond of
the Data::FormValidator module.


TTYL,

-Jesse-

Reply via email to