> From: Jesse Erlbaum [mailto:[EMAIL PROTECTED]]
> Sent: 07 June 2002 18:58
> The purpose of the controller is to validate input and construct
> valid arguments into these model methods.
Jesse, maybe its just semantics coming between us - if so, I apologise
in advance!
I think that the purpose of the Controller is to map User Input onto
Model properties and methods. The validation of any of the properties,
Model parameter calls etc must be in the Model, otherwise every
Controller that uses a Model must duplicate all the validation.
Let's say for example that I have a generic page with lots of fields,
that lets you create a Payment Instruction from your bank account.
Payment Instructions can be domestic or international. When you fill in
the details and hit submit, our Controller gets poked in the belly.
It is not reasonable for the Contoller to know that when creating an
International Payment, that the instruction dates for Italy must be at
least five working days in the future, and must not fall on an Italian
bank holiday. This is information that the Payment Instruction Model
should validate.
It is also not reasonable for a Controller to know that when creating
Swiss Blue Slip International Payments, that in addition to all the
other usual required fields, a 15 digit creditor reference number is
also required.
The responsibility of the Controller is to take all the supplied user
input, translate it into the correct format, and pass it to the Model,
and watch what happens. The Model will decide if the instruction can be
realised, or if the system should explode.
The only type of validation that a controller _might_ perform would be
data type - e.g. is this a recognisable date? but even then it may may
more sense for the Model to interpret it. For example, a US Payment
Instruction might interpret 04/15/02 [15th April] as valid, but a UK
Payment Instruction might consider this a bad joke [4th day of 15th
month?].
Such basic type validation is often pushed to the Client in JavaScript,
to make for a 'richer user experience', but in any case would still need
to be checked - either in the Controller or Model.
It is a valid job of the controller to TRANSLATE input parameters into
an acceptable format for the Model. For example, it is valid to URL
Decode a string before passing it to a Model. The URL decoding is a
direct consequence of the way in which the user is interacting with the
Model, and hence a valid thing for a Web Controller to do. URL decoding
should not be in the Model, as it would have no relevance when the Model
is used in a cron job. There is a difference between translation and
validation.
> The controller is also responsible for catching any exception from the
> methods it calls ... 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.
I agree that this is a problematic area that needs some careful advance
thought, and a protocol whereby the Controller is told that something
went wrong - the Controller might well choose to instantiate a different
View after an exception.
> 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
Maybe I am miss-understanding your 'valid arguments'? Because I disagree
- Models must validate themselves. You DON’T want to duplicate
validation code and tests in both the Web Controller and the cron job
Controller.
£0.2
Regards
Jeff
