On Mon, 13 Jan 2003, Ted Husted wrote:
> Date: Mon, 13 Jan 2003 17:40:38 -0500 > 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 > > Can we also migrate the Message carrier [o.a.s.a.ActionMessages] and > Message element [o.a.s.a.ActionMessages] to Commons Resources? > That makes sense to me. There's lots of scenarios for transfer of individual messages, or message lists, between application tiers. > 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. > +1 -- go for it. Don't forget to add yourself as a committer ... How about if you create o.a.c.r.Message and o.a.c.r.MessageList? > -Ted. > Craig > > 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-resources/ > > > > 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]> > > -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
