struts-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Ray Clough" <...@allthisisthat.com>
Subject Re: [s2] Is it possible to replace/supplement i18n resolution logic?
Date Sat, 04 Aug 2007 09:53:51 GMT
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" <donald.brown@gmail.com>
> 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 <matt@raibledesigns.com> 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: user-unsubscribe@struts.apache.org
> > For additional commands, e-mail: user-help@struts.apache.org
> >
> >
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
> For additional commands, e-mail: user-help@struts.apache.org

>



- Ray Clough
ray@allthisisthat.com



---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org


Mime
View raw message