Jonathan Fuerth wrote: > This seems to break the MVC design pattern though, because now the > controller contains information the belongs to the view (message keys) > and is making decisions that are the responsibility of the model > (handling the exceptions that the model generated). Or is it, in > fact, the controller's job to do exception handling? If so, what > mechanism in MVC generates the error message that the user sees?
IMHO, the messages and the messages keys belong to the model. The controller is simply transferring this data to the view, as it does with everything else, like records from a database. The view's only responsibility is to markup the data it receives (which is really quite enough these days). In most cases, exceptions can be converted to ActionErrors. I would try and do all of this in the Action, so that the view doesn't have to "think" about anything. Also, in the Action it is much easier to access utility methods to parse the exception for you. A base method for your Actions might be able to do everything; so in the main perform, all you end up doing is passing back the instant request, ActionError object, and the exception. A base method could handle it from there. If you are using the nightly build, you might have the controller add a user-friendly error first, and then post the detail from the exception. This way everybody is happy. You can do this with 1.0.x too, but the order in which they are displayed is not defined. Another approach would be to pass the exception under a known key in the request, as the Struts JSP tags do, and have your page display the exception message separately (when there is one). -- Ted Husted, Husted dot Com, Fairport NY US -- Developing Java Web Applications with Struts -- Tel: +1 585 737-3463 -- Web: http://husted.com/about/services Jonathan Fuerth wrote: > > I'm refactoring an existing web application into the Struts MVC > framework, and I'm moving from the implementation planning to the > coding stage now. Before I act on some potentially poor choices, I'd > like to run some of my ideas past the group: > > The Model part of my application, which handles all the SQL database > interaction and business logic, will inevitably encounter semantically > incorrect user input that the ActionForms in the view could not have > known was incorrect (example: invalid username/password on the login > screen). Some of these semantic errors will result in SQLExceptions > and the like, which the view (JSPs, ActionForms) should not have > visibility to. > > My knee-jerk reaction to this problem was to have the controller > (Action class) catch these exceptions and add ActionErrors to the > response, indicating appropriate message keys which the JSP could > display in the user's favourite language. > > This seems to break the MVC design pattern though, because now the > controller contains information the belongs to the view (message keys) > and is making decisions that are the responsibility of the model > (handling the exceptions that the model generated). Or is it, in > fact, the controller's job to do exception handling? If so, what > mechanism in MVC generates the error message that the user sees? > > My current plan of attack is to create a custom exception class for > everything that could go wrong while the model is doing its thing, and > let them pass through my Action classes to the JSPs. The JSPs will > handle the exceptions by cross-referencing the exception type to a > message key.. and the user will get an error message in their native > language. > > The main problem with this approach is that a lot of things can go > wrong in an application, and this will entail a large number of > exception classes. An ultimate goal of MVC is to keep the application > maintainable as it grows. A large number of documented exceptions > *seems* reasonably maintainable... but I haven't started coding yet. :) > > So, I hope to learn from your experiences. What have you people done > when a login fails, a database goes away, a resultset overflows, or > other nasty things happen to the business layer? > > Thanks! > > -- > Jonathan Fuerth - SQL Power Group Inc. > (416)218-5551 (Toronto); 1-866-SQL-POWR (Toll-Free) > Unleash the Power of your Corporate Data - www.sqlpower.ca > > -- > To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> > For additional commands, e-mail: <mailto:[EMAIL PROTECTED]> -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
