I like the idea. While your at it, can each message pass in its own resource bundle so you can keep the resources with the Class/Package?
Edgar -----Original Message----- From: Ted Husted [mailto:[EMAIL PROTECTED]] Sent: Monday, January 13, 2003 6:15 PM To: Struts Developers List Subject: Re: [Proposal] Migrate to Dependency on commons-resources I am using them outside of Struts now, and it makes perfect sense =:0) It's important to remember that the idea of a message resource is generic to an application and is not a Struts concept. If something occurs on the domain layer, the enterprise application should be able to return the information using the same tokens as the presentation tier. Or, more properly, the presentation tier (Struts) should use the same tokens as the rest of the application. =:> Struts uses the ApplicationResource but the underlying idea is it belongs to the application generally (hence, the name). It's actually very difficult to write an multi-tier i18n enterprise application with something like the (Action)Messages. There are a ton of messges that you want to return from the domain, including confirmation messages (like "record #63 inserted"). Meanwhile, the Commons Validator also has the idea of a Message carrier (like ActionMessages) at its core, and there should be a generic implementation of this object in the Commons, whether Struts uses it or not. -Ted. David Graham wrote: > ActionMessages doesn't make sense outside of Struts. It would need a > new name at the least. If we move them to commons, they should become > interfaces with some default implementations. Then people would be free > to plugin their own implementation. > > I think they're fine staying in Struts for now; 2.0 might be a better > time to look at this architecture. > > David > > > > > > >> From: Ted Husted <[EMAIL PROTECTED]> >> Reply-To: "Struts Developers List" <[EMAIL PROTECTED]> >> To: Struts Developers List <[EMAIL PROTECTED]> >> Subject: Re: [Proposal] Migrate to Dependency on commons-resources >> Date: Mon, 13 Jan 2003 17:40:38 -0500 >> >> Can we also migrate the Message carrier [o.a.s.a.ActionMessages] and >> Message element [o.a.s.a.ActionMessages] to Commons Resources? >> >> The idea being a domain logic object may like to return a collection >> of Messages to the presentation tier. (At least mine would!) >> >> I'm thinking someone should be able to offload the whole >> ActionForm.validate() mechanism to the domain tier, and just use >> Struts to reconcile and display the messages according to the client's >> locale. >> >> I've actually already started to generalize ActionMessage/s. for this >> purpose. At one time, I think Martin and I were talking about putting >> it somewhere in the Commons, but I forget which package now. Resources >> makes sense to me. =:0) >> >> So, then, ActionMessages would also become a wrapper around a Commons >> class and would also encapsulate the Struts globals. >> >> Of course, I am volunteering to port the code, if that's what we want >> to do. >> >> -Ted. >> >> >> Craig R. McClanahan wrote: >> >>> As we've discussed a couple of times, the last major functionality >>> change >>> we had discussed for Struts 1.1 was to migrate to dependence on >>> commons-resources, rather than the proprietary message resource >>> facilities >>> inside og.apache.struts.util. As you might recall, Michael Schacter >>> took >>> a first crack at factoring out the Struts resources classes out to >>> create >>> this commons package, which is currently in the sandbox. >>> >>> I've recently gone through it, and did a major refactoring of >>> commons-resources, to the point where I'm now ready to propose that >>> we modify Struts to depend on it. I'd like the other committers to >>> evaluate the current state of commons-resources, and my proposed >>> integration plan below, to see what they think of this idea. >>> >>> The nightly build of commons-resources.jar included in recent Struts >>> nightly builds is the code that I'm proposing. You can see the >>> Javadocs for this code at: >>> >>> http://jakarta.apache.org/commons/resources/api/ >>> >>> and get the sources via either CVS (from jakarta-commons-sandbox) or >>> nightly snapshots: >>> >>> >>> http://jakarta.apache.org/builds/jakarta-commons/nightly/commons-res >>> ources/ >>> >>> >>> In terms of Struts integration, I propose: >>> >>> (1) Most Struts classes declare a static MessageResources instance >>> for the messages unique to that Struts package. For example, >>> org.apache.struts.taglib.bean.CookieTag has this: >>> >>> protected static MessageResources messages = >>> MessageResources.getMessageResources >>> ("org.apache.struts.taglib.bean.LocalStrings"); >>> >>> This would be migrated to the new Messages class from >>> commons-resources: >>> >>> protected static Messages messages = >>> Messages.getMessages("org.apache.struts.taglib.bean"); >>> >>> The calls to actually retrieve message strings are compatible with >>> the existing code, as well as the properties files used to acquire >>> the message strings, so no other changes should be required. >>> >>> (2) Convert o.a.s.u.MessageResources (and its friends) to wrappers >>> around equivalent functionality from commons-resources (much like >>> GenericDataSource now wraps commons-dbcp), and deprecate them. >>> This protects existing apps that are customizing these APIs, >>> but allows us to remove the o.a.s.u classes in a future version. >>> >>> (3) Modify the <message-resources> initialization element to allow >>> the selection and configuration of an appropriate >>> ResourcesFactory from commons-resources, wrapped by a Messages >>> instance. This is primarily a change in the interpretation of >>> the "factory" attribute, and should not affect anyone that uses >>> the current default. >>> >>> (4) Modify all internal uses (including in tag libraries) of >>> org.apache.struts.util.MessageResources to use >>> org.apache.commons.resources.Messages instead. This will be >>> transparent to users that use the standard implementations, but >>> will require folks who have subclassed the MessageResources >>> classes to migrate their code as well. >>> >>> What do you think? Should we go ahead and do this migration? Is >>> the commons-resources package as it stands now as complete and >>> functional as it needs to be (obviously, it'll need to be promoted >>> to a standard Commons package and released so we can rely on it, >>> which will require a couple of >>> volunteers willing to help me maintain it). Should we do the entire >>> migration outlined above, or maybe only part of it? >>> >>> Thoughts, please. >>> >>> Craig >>> >>> >>> >>> -- >>> To unsubscribe, e-mail: >>> <mailto:[EMAIL PROTECTED]> >>> For additional commands, e-mail: >>> <mailto:[EMAIL PROTECTED]> >>> >>> >> >> >> -- >> Ted Husted, >> Struts in Action <http://husted.com/struts/book.html> >> >> >> -- >> To unsubscribe, e-mail: >> <mailto:[EMAIL PROTECTED]> >> For additional commands, e-mail: >> <mailto:[EMAIL PROTECTED]> > > > > _________________________________________________________________ > Help STOP SPAM: Try the new MSN 8 and get 2 months FREE* > http://join.msn.com/?page=features/junkmail > > > -- > To unsubscribe, e-mail: > <mailto:[EMAIL PROTECTED]> > For additional commands, e-mail: > <mailto:[EMAIL PROTECTED]> > > -- Ted Husted, Struts in Action <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]>
