I would agree that your model should not be manipulating ActionError(s).
If your requirement is that you MUST send multiple errors back from the
model then perhaps a custom exception (with a list of other exception,
errors string, or keys to i18n, internal to it), that you can pick apart in
the Action:perform( ... catch (...)). If you think that multiple model
errors is a down-the-road thing, take the XP route and implement a solution
for single errors, then when the feature becomes required you can use your
knowledge gained from the first pass to implement the multiple way.
Tim
"Donald Ball"
<dball@rhowor
ld.com>
09/06/2002
10:11 AM To: [EMAIL PROTECTED]
Please cc:
respond to
"Struts Users
Mailing List"
Subject: how to return errors from Model
component
Caterpillar: Confidential Green Retain Until: 10/06/2002
Retention Category: G90 -
Information and Reports
Hey guys, I have an MVC-type question. My View captures data from the user
and sends it to the Controller, which validates and massages it and uses it
to configure the Model and tell the Model to do something. Based on the
something, the Controller sends another View to the client. So far so good.
What happens when something, or rather, somethings go wrong when the Model
is doing its work? How should the Model communicate this to the Controller
in a way that doesn't violate the seperation of concerns? Currently, my
Model creates a struts ActionErrors object and puts the error messages into
it and returns it to the Controller. This strikes me as a bad design choice
because the Model object shouldn't have any notion of the environment in
which it lives. However, I'm unsure what the best practice is. Choices
include:
* Tossing an exception - but I would like to be able to send multiple
errors at the same time
* Return a List or array of String error messages - but then my messages
are hard-coded into the application, making i18n painful. I could make the
Strings returned be keys into the ApplicationResources properties file, but
then how do I attach parameters for messages that need them?
* Return, oh, a SortedMap of error messages, where the keys are the error
message keys, sorted in order of occurance, and the values are Lists of
parameters for the error messages - but this seems awfully convoluted.
Any suggestions?
- donald
--
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]>
