We should include/improve a flash result/scope for 2.2: https://issues.apache.org/struts/browse/WW-2635
an yes, we should start drafting some sort of roadmap. musachy On Fri, Apr 24, 2009 at 12:49 PM, Rene Gielen <[email protected]> wrote: > 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 <[email protected]> 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 <[email protected]> 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: [email protected] >>>> For additional commands, e-mail: [email protected] >>>> >>>> >>> >>> >>> -- >>> "Hey you! Would you help me to carry the stone?" Pink Floyd >>> >>> --------------------------------------------------------------------- >>> To unsubscribe, e-mail: [email protected] >>> For additional commands, e-mail: [email protected] >>> >>> >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: [email protected] >> For additional commands, e-mail: [email protected] >> > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > > -- "Hey you! Would you help me to carry the stone?" Pink Floyd --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
