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]>
