to add some ideas that came to my mind lately: Rework on i18n support 1. create a TextProviderNextGen component that can easily be used and injected 2. create a TextProvider interceptor which - sets up a TextProvider - sets it on an Action implementing TextProviderAware interface - pushes the TextProvider on the stack to have a mixin/"trait"-like functionality 3. make formats easier to use in tags (textfield, property, select etc) - add a "format" property to name a text format to apply to the value - provide predefined default formats like number, money, percent
comments: 1. The new component would give us the opportunity to get out of the TextProvider hell without braking backwards compatibility 2. Extracting TextProvider functionality to an aspect would remove the main reason to extend ActionSupport. While Actions would explicitly declare their need for TextProvider as a component, the view developer would still be able to use getText(...) expressions directly (via TextProvider residing on the stack), without the need to write textProvider.getText(...) given TextProviderAware introduces a textProvider property on the action. 3. Although the use of getText expressions provide all the needed functionality for i18n/l10n support, they are quite clumsy to use when it comes to the widely used pattern of applying text formats to numbers and dates. Adding a convenience property named format would held view developers to get very easy access to those formats, without the need to understand the getText signatures (I have to constantly look it up again) for their most common use cases. Providing some reasonable default formats would make it work out of the box, while the developer could define additional formats as well as use getText expressions like before when it comes to multiparameter formats etc. That said, should we go to setup a (s|x) 2.2 roadmap in Confluence? - Rene Don Brown schrieb: > Off the top of my head: > * Split out the XML parser from XmlConfigurationProvider so that you > can parse XML from any source > * Get rid of all the Class.forName() calls in XWork > > I'd rather not do this on a stable branch, particularly since new > public classes will be created. How many changes are there in 2.1.7 > and 2.1.3 that haven't been released? Could we get those releases out > the door so we know we branch at a known good state? > > Don > > On Fri, Apr 10, 2009 at 11:25 PM, Musachy Barroso <musa...@gmail.com> wrote: >> I think we are good. What changes do you have in mind?, the OSGi >> plugin could take advantage of some refactoring of xwork so I am >> interested :) >> >> musachy >> >> On Fri, Apr 10, 2009 at 8:24 AM, Don Brown <mr...@twdata.org> wrote: >>> Now that 2.1 is GA (thanks guys and gals), are we ready to branch it >>> off and move trunk to 2.2? I was wanting to do some refactoring of >>> how XWork configuration is loaded and parsed, but new classes and the >>> like really isn't appropriate for a patch/micro release. >>> >>> Any objections to the branching? >>> >>> Don >>> >>> --------------------------------------------------------------------- >>> To unsubscribe, e-mail: dev-unsubscr...@struts.apache.org >>> For additional commands, e-mail: dev-h...@struts.apache.org >>> >>> >> >> >> -- >> "Hey you! Would you help me to carry the stone?" Pink Floyd >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: dev-unsubscr...@struts.apache.org >> For additional commands, e-mail: dev-h...@struts.apache.org >> >> > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@struts.apache.org > For additional commands, e-mail: dev-h...@struts.apache.org > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@struts.apache.org For additional commands, e-mail: dev-h...@struts.apache.org
