Thanks for the comments. So if my model was going to throw an error about a duplicate row, for example, you'd throw that as an exception then let the controller deal with that (i.e. format a nice error message for the user, or something)?
Thanks. -Justin On 5/16/07, Ralph Schindler <[EMAIL PROTECTED]> wrote:
Think of the controller/action the place to take user input, filter it, and pass it to the model. Generally speaking, the controller should be completely aware of what inputs your view is sending back (via the form naturally). If the controller is not getting the values (from $_POST or wherever), its the controllers job to pass some information to the view to alert the user. I like to think of models in such a way that they can operate in a platform independent manner, or in other words.. I can drop the same models I use in a web app, into a commandline version of the same app, and the models should not have to be altered in any way. If for some reason, you have not satisfied a requirement for a model, I generally allow it to throw an exception (as Zend_Db_Table_* does) and handle it gracefully in the controller. Those are just some ideas to start kicking around. -ralph Justin Plock wrote: > I'm trying to convert over an existing site over to using Zend_Db and > Zend_Controller. I've got some error checking code in my > Zend_Db_Table classes to make sure all of my required values are > populated. I'm just asking in terms of a best practice, should this > sort of error checking be moved up to the Controller so it is easier > to communicate the error messages back to the user or do you think it > should be tied to the Zend_Db_Table? > > Just looking for suggestions. > > Thanks. > > -Justin >
