I am not sure I understand this proposal. As far as I know this is already supported by WW and quite nicely. So, why would we want to add just another dependency?
./alex -- .w( the_mindstorm )p. --- (http://themindstorms.blogspot.com) On 6/30/06, Don Brown <[EMAIL PROTECTED]> wrote:
If Struts 1 decided to go with Cintoo, I think it would be good for Struts 2 to adopt it as well, as it would make migration easier, and reduce the number of differences between the two versions. I'd like to take that approach with other areas like validation and annotations in the future. Don Niall Pemberton wrote: > On 6/30/06, Paul Benedict <[EMAIL PROTECTED]> wrote: >> Joe Germuska <[EMAIL PROTECTED]> wrote:That said, I don't think you >> should not do the work you describe, >> just because you may have to leave the Localizer (or whatever you >> call it) in the ServletContext under a well known key. It's just >> that it feels so outdated! >> >> Here's my solution. Unless anyone feels strongly about it, I am going >> to open up a ticket and submit my patch. >> >> 1) I am going to retain the Globals.LOCAL_KEY as the constant for >> session-strategy localization. Previous applications will continue >> using this without a problem. >> >> 2) I am going to add a LOCAL_RESOLVER_KEY constant which returns an >> object that implements these methods: >> >> Locale resolveLocale(HttpServletRequest request); >> >> >> void setLocale(HttpServletRequest request, HttpServletResponse >> response, Locale locale); >> >> >> These methods will not be of any interface. The resolver object can be >> any class which implements those two methods, and I will use BeanUtils >> to retrieve them. The reason I am choosing this design over an >> interface is because I want to plug in implementations from any >> framework (like Struts2 or Spring) without requiring an adapter >> interface. At most, the adapter interface would be just a pass-through >> and so it has questionable value. >> >> 3) Modify RequestUtils.getUserLocale to lookup the stategy first and >> use it. RequestUtils will have a pre-built strategy for doing session >> look-up, to implement requirement #1 (see above). >> >> 4) Modify Action.get/setLocale to delegate to the locale strategy. The >> retrieval of the strategy will most likely be in RequestUtils. >> >> If this works right, I should be able to punch to bridge Struts 1, >> Struts 2, and Spring all behind the scenes. For those developing >> Struts 2, do you have any class which comes close to the above? I'd >> like to coordinate with you so that Struts1-Struts2 apps can bridge >> localization in the 2.0.0 release. > > I had a quick peek at Cintoo messages today (Apache 2 license) - > initial impression was its a nice implementation for i18n. They use > ThreadLocale to store the Locale which makes it available everywhere. > I believe that approach has been used by the ww guys and from memory I > think there are similar concepts for configuring resources > (packaging). It would interesting to hear one of the WW guys if they > had time to look at it. Perhaps we can use it to do the job Commons > Resources was intended for. > > Anyway I digress, this would be one way of making Locale available all > over the place (messages, validation, tiles) without necessarily > changing the API. > > http://messages.cintoo.org/ > http://www.theserverside.com/news/thread.tss?thread_id=41116 > http://www.infoq.com/news/Cintoo-Messages-1.0-i18n > > Niall > > P.S. don't look at the cintoo site using IE - its a mess - OK in firefox > though. > >> I am targetting 1.3.6+ >> >> Paul > > --------------------------------------------------------------------- > 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]
