-- Justin Plock <[EMAIL PROTECTED]> wrote
(on Wednesday, 16 May 2007, 07:16 PM -0400):
> How would I do something like this:
>
> 1.) present a form to the user
> 2.) user submits it and an error is generated
> 3.) either the controller or the model throws an exception
> 4.) the user will be presented with the same form they filed out, with
> all of their values still populated, but an error message would be
> displayed.
>
> How would I do something like that using the ErrorHandler plugin?
You wouldn't. In this particular case, you'd trap the error when
processing the form, capture the values submitted, and then forward back
to the action that generates the form. Here's how I commonly do this:
public function init()
{
$this->initView();
}
public function formAction()
{
$this->render();
}
public function processAction()
{
// assume some sort of validator
$validator = new My_Validator($_POST);
if (!validator-> isValid()) {
$this->view->values = $_POST;
// Assume that validator object retains errors as key/value
// pairs
$this->view->errors = $validator->getErrors();
// Back to the form...
return $this->_forward('form');
}
// successful, so do something else...
}
This will populate the form with values and errors, which you can have
the form view script optionally inject.
> On 5/16/07, Matthew Weier O'Phinney <[EMAIL PROTECTED]> wrote:
> > -- Justin Plock <[EMAIL PROTECTED]> wrote
> > (on Wednesday, 16 May 2007, 04:11 PM -0400):
> > > 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)?
> >
> > Yep. Or you could ignore it in your controller, and use the new
> > ErrorHandler plugin (enabled by default) to display an error message via
> > your ErrorController.
> >
> > (I just moved the ErrorHandler controller plugin to core this afternoon.)
> >
> > > 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.
--
Matthew Weier O'Phinney
PHP Developer | [EMAIL PROTECTED]
Zend - The PHP Company | http://www.zend.com/
