We did something similar to what you are suggesting. We still use properties files, but we replaced much of the lookup with our own classes. We created a wrapper around ResourceBundle which has overloaded 'getText()' methods. We make this accessible to all parts of the app with a ThreadLocal object which incorporates the current Locale, and has a 'getMessageProvider()' method. The 'MessageProvider' has the 'getText(key, args)' methods. We did this because the non-Struts modules of the app need Message Support also, and so in order to keep the Struts artifacts out of these modules, we did the extra work. The process of replacing messaging in the JSP pages was too daunting, so we still use the S2 tags to resolve those messages. Our module uses the same ResourceBundle files as the Struts module. However we created our own tag library to replace the s:text tag in some instances where the action isn't S2 (sometimes it is S1, sometimes it is JSF). I think the ideal solution would be to move all the messaging resources into a new Commons project (commons-messaging??), and to access to the messaging service as an interface abstraction. That way the choice of messaging service would be more flexible.
Changing the S2 messaging system would require overriding the 'getText()' methods in the ActionSupport class, as well as changing the way that the S2 tags get their messages. That would be a pretty huge job, and would take a huge amount of refactoring of the S2 code base. However, IMHO the S2 tags are really poor, so replacing them completely with a new library would be an excellent step. What I dislike most about the S2 tags is that their syntax is confusing, and very un-jsp-like. They don't allow runtime expressions (like the jstl tags), requiring the use of s:set to create properties which are then de-referenced in the UI tags. Also the syntax for accessing OGNL is particularly incongruous. Some tags require using both a "%" and a "#" within one tag. A lot of this is the result of trying to make a tag library that is flexible enough to work in environments other than JSP, but I believe a lot of it is due to the 'hobby-like' nature of S2 (I was not involved, so this is speculation on my part). The evolution of WebWork from Struts allowed the WW developers to 'try things out', and when the project was remerged into S2, many design decisions which should have been reversed were found to be too much trouble. So the 'try things out' features remain to bedevil the S2 application architecture. The very worst feature (again IMHO) is the mandatory use of themes. The other very worst feature is the result 'type' feature which mandates that only one rendering type can be used in any one page. For example, if you are using the Tiles plugin with 'type=tiles', you can't use the jsf plugin with 'type=jsf'. This has mandated that we don't use any plugins at all. Of course, this isn't a big loss because the most of plugins are very very very ... very buggy and do not appear to be in current development, as judged by their still poor implementations. Another very worst feature is the translation of the word "POJO" to equal "Java Bean", and means that everything has getters and setters everywhere, which makes the apps developed with it poorly encapsulated and difficult to maintain (the designers of S2 definitely did not read, or did not comprehend, or did not believe, the central theme of "Why Getters and Setters are Evil"). Sorry for the rant, but I do like many of the S2 features well enough that I continue to use it, and the S2 architecture is definitely better than S1 (death to ActionForm!). - Ray Clough > ----- Original Message ----- > From: "Don Brown" <[EMAIL PROTECTED]> > To: "Struts Users Mailing List" <user@struts.apache.org> > Subject: Re: [s2] Is it possible to replace/supplement i18n resolution logic? > Date: Sat, 4 Aug 2007 12:30:09 +1000 > > > On 8/4/07, mraible <[EMAIL PROTECTED]> wrote: > > > > With Struts 2, how would I go about doing the following: > > > > 1. Replace the i18n resolution logic to load key/value pairs from a database > > instead of properties files? > > Well, if your Action class implements TextProvider (as does > ActionSupport), then you can resolve keys any way you'd like. As for > plugging/altering the existing lookup that is used by ActionSupport, > it really isn't possible right now, and I've love to see a patch > making that more flexible... *hint* *hint* :) > > > 2. Add an extra processing step to translate wiki syntax in values to HTML? > > You mean like creating your own template to customize the rendering of > the control? If using Freemarker, there might be a nice way to write > something like the ?html piece that processes returned values. > > Don > > > > > Thanks, > > > > Matt > > -- > > View this message in context: > > http://www.nabble.com/-s2--Is-it-possible-to-replace-supplement-i18n-resolution-logic--tf4214304.html#a11989382 > > Sent from the Struts - User mailing list archive at Nabble.com. > > > > > > --------------------------------------------------------------------- > > 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] > - Ray Clough [EMAIL PROTECTED] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
