I want to use it with my business classes so they can pass messages back to the presentation tier. I started by passing back flat messages, but found I also wanted a category. In this case, the category relates to the name of a field that failed a business tier validation. In a Struts environment, the field is represented by a property on a bean. But from the business classes perspective, it is a field.
Besides fields, you might also use it to group other types of information together. Each property could be a question on a questionnaire, and each message a response to the question. And so forth. In general, I would cast it as a flavor of data transfer object. You could use it custom tags and JavaBeans. But someone else could also use it with Velocity or XLS or whatever. The underlying idea is the messages often need to be grouped together or targeted in some way, and the Messages container gives you a way to do that. Another point is that it also provides functionality that a simple Hash Map does not, since you can have multiple messages related to a specific [property,topic,subject,category]. So, it we were to place it someplace else, I'd suggest Collections. I believe add could just as well take an Object. Basically, it's a container that let's you "pigeon hole" entries using arbitrary categories. -T. Martin Cooper wrote: > >>-----Original Message----- >>From: Ted Husted [mailto:[EMAIL PROTECTED]] >>Sent: Monday, September 09, 2002 2:01 PM >>To: Struts Developers List >>Subject: Re: commons.resources.messages >> >> >>The JavaDocs talk about "beans" and "properties", but that >>seems to be >>just nomenclature. The ActionMessages container doesn't seem >>linked to >>JavaBeans in any specific way. The Strut's framework associates the >>message categories with bean properties, but that's just one >>potential use. >> > > I kind of agree, but for one thing. In my own mind, I can't come up with a > good explanation (excepting beans) of why I would want to have a collection > of messages in which each message could be associate with a particular > property name, or with some non-specific name. In other words, I can't > imagine what the Javadoc for this class is going to say regarding why I > would ever want to use it. > > That seems to suggest, to me at least, that either the class really does > need to be associated with beans, or what we have now is not sufficiently > generic to be useful elsewhere. Or that I have a poor imagination. ;-} > > -- > Martin Cooper > > > >>The cleanest thing might be to update the JavaDocs and >>statics to remove >>the Struts references, import it to Commons resources, and do any >>additional refactoring there. Then, post 1.1, we can bring >>the Commons >>version back in again (which now seems to be SOP). >> >>-Ted >> >>Martin Cooper wrote: >> >> >>>I don't see a reason that ActionMessage needs to be in >>> >>Struts, since it's >> >>>really just a way to group the key with the intended >>> >>placeholder values. >> >>>Moving it to Resources seems like a minimal extension of >>> >>that component's >> >>>scope. >>> >>>I'm a little less sure about ActionMessages. I don't think >>> >>it necessarily >> >>>needs to stay in Struts, but it does have a clear linkage >>> >>to beans, since >> >>>the 'property' of an ActionMessages entry refers to a bean >>> >>property. As a >> >>>result, it's not so clear to me that it's a good fit for Resources. >>> >>>I'd almost be tempted to put (Action)Message in Resources and >>>(Action)Messages (perhaps as PropertyMessages) in BeanUtils. >>> >>>While we're on the subject, another point was brought up >>> >>recently regarding >> >>>ActionMessage(s) (and ActionError(s)), which I have also >>> >>run afoul of. The >> >>>issue is that these classes do not allow the association of >>> >>a bundle with >> >>>the message key. This is most commonly a problem with the >>> >>collections of >> >>>messages, since there is no way to build up a collection of >>> >>messages which >> >>>contain keys which refer to different bundles. >>> >>>There are several ways that this could be addressed, and >>> >>not all of them >> >>>require changes to these classes. However, it's an issue >>> >>worth considering >> >>>if we're also considering moving these classes elsewhere. >>> >>>-- >>>Martin Cooper >>> >>> >>> >>> >>>>-----Original Message----- >>>>From: Ted Husted [mailto:[EMAIL PROTECTED]] >>>>Sent: Monday, September 09, 2002 8:45 AM >>>>To: [EMAIL PROTECTED] >>>>Subject: commons.resources.messages >>>> >>>> >>>>Would there be any objections to contributing the ActionMessage/s >>>>classes to the Commons Resources package (as Message and >>>> >>Messages, or >> >>>>equivalent). >>>> >>>>I'm starting to use the properties field on the message more >>>>often, and >>>>would like to pass this back from the business tier. I'd rather not >>>>import the Struts class or replicate the class structure, for >>>>the usual >>>>reasons. >>>> >>>>It seems like it would be a good fit for the Commons Resource >>>>package, >>>>and I'd be happy to bring it over. >>>> >>>>I brought it up here first in case there was any reason for >>>>keeping it >>>>only the Struts codebase. Of course, I am not suggesting we >>>> >>move any >> >>>>Struts dependencies at this time. >>>> >>>>-Ted. >>>> >>>> >>>>-- >>>>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]> >> >>> >> >>-- >>Ted Husted, Husted dot Com, Fairport NY US >>co-author, Java Web Development with Struts >>Order it today: >><http://husted.com/struts/book.html> >> >> >>-- >>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]> > > -- Ted Husted, Husted dot Com, Fairport NY US co-author, Java Web Development with Struts Order it today: <http://husted.com/struts/book.html> -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
