Ray Clough wrote:
>
> 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
>
Do you have a list of specific issues you've seen with the JSF Plugin? It'd
be nice to get these documented so 1) users can be aware of them and 2)
developers/contributors can fix them.
Also, if you believe getters and setters are evil, what's the solution? Most
of the Java web frameworks I know of today use getters and setters to
read/set values. Are getters and setters evil in your Hibernate/JPA POJOs as
well?
Matt
--
View this message in context:
http://www.nabble.com/-s2--Is-it-possible-to-replace-supplement-i18n-resolution-logic--tf4214304.html#a12023507
Sent from the Struts - User mailing list archive at Nabble.com.
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
