How would a change to the View require a change to the validation?
Ideally, the View should be completely separate from business logic
(Controller & Model). A change to the View should have no effect
on the validation of the form elements.
I can fully appreciate the debate between putting data validation
within the Model or Controller. The use cases against putting
validation in the Model are incoming data does not always flow to the
Model and data flowing to the Model does not always need to be
validated. IMO, the validation needs to be its own object instantiated
in the Controller
because it shares its duties between validating the incoming data and
alerting the View to validation errors.
I guess the majority of this debate comes down to how you design the
form, the validation of the form, how the validation communicates to
the View, and retrieval and/or storage of data from the form. My system
is a lot like what Michael Minicki described on the Zend_Form proposal
which has molded my opinions on this subject:
http://framework.zend.com/wiki/display/ZFPROP/Zend_Form?rootCommentId=3957#comments
Dale
Jean-Baptiste HUNTZINGER wrote:
>> MO, data validation should not be performed within the model
but rather in the controller
There is definitively many opinions about Validation in MVC, but I
still don't agree with your statement. I want a solution that does not
oblige me to rewrite my validation code each time my View changes -
either I change the UI logic or the client technology -, since
controller is tighly bound to the view.
Model has all the info needed to performs the validation, and
validation is purely domain logic, no ?
Dale McNeill a écrit :
IMO,
data validation should not be performed within the model but rather in
the controller. The controller could query the Table/Row for validator
objects but its the controller that should perform all the validating
of data.
One thing that I would like to see in a future Zend_Db_Table is the
storage of the entire "describe <table>" rather than only storing
the column names. Why? Well I've changed the Table to store this
information so that the controller can query the Table for the
fundamental validator objects. A "varchar(30)" can provide a validator
that restricts the the length to 30 characters; a "int(10)" can provide
an integer validator that restricts the maximum value to a 10 digit
signed integer. I think in general the results of the describe table
is very useful and certainly worth storing all the information. It
could even be used to set the default values of any unset columns when
performing an insert.
Dale
Stuardo -StR- Rodríguez wrote:
On Wednesday 27 September 2006 00:47,
Victor
Bolshov wrote:
Could you please tell in more detail -
what
you mean by "a model in MVC"?
I mean a model, in the context of Model-View-Controller. As you can see
in http://en.wikipedia.org/wiki/Model-view-controller
<blockquote>
Model: The domain-specific representation of the information on which
the application operates. The model is another name for the domain
layer. Domain logic adds meaning to raw data (e.g., calculating if
today is the user's birthday, or the totals, taxes and shipping charges
for shopping cart items).
</blockquote>
So.. from where I see.. the controller should create a model to get
data or to return data, from wherever you want (DB, XML, RPC, log,
etc). The controller should know "the action" what should be done, the
bussiness logic. The model should know what to do with the data,
validate the data, and all what is related with data.
Now, I do not see any solution for that in ZF and I thought
Zend_Db_Table could be use as a solution, but I was wrong and I started
the post to see if anyone had the same idea and if anyone has solved
that.
I said "Model in MVC" to let people understand the context, so no one
gets confused with "a model/guide to follow" or "a hot-long-legs-model"
|
