[s2] Is it possible to replace/supplement i18n resolution logic?

[mraible <ma...@raibledesigns.com>]

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?
2. Add an extra processing step to translate wiki syntax in values to HTML?

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

Re: [s2] Is it possible to replace/supplement i18n resolution logic?

[Zarar Siddiqi <za...@gmail.com>]

> 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* :)
>

Am I crazy or would this be as simple as having a setTextProvider()
method in ActionSupport that would (take a guess..) set the
textProvider which is currently private in ActionSupport.  Then when
you're configuring your actions with say Spring, you could pass your
own TextProvider singleton bean.

Zarar

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

Re: [s2] Is it possible to replace/supplement i18n resolution logic?

[mraible <ma...@raibledesigns.com>]

Don Brown wrote:
> 
> On 8/4/07, mraible <ma...@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* :)
> 

Does this affect <s:text> as well? I'm not as concerned about Java reading
i18n files as I am about JSPs.


Don Brown wrote:
> 
> 
>> 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.
> 

No, I'm looking to add an extra process step. Here's an example, using JSTL
<fmt:message> since I'm more familiar with it:

messages.properties:
page.message=Welcome to My Cool App *{0}*!

page.jsp:
<fmt:message key="page.message"><fmt:param
value="${user.firstName}"/></fmt:message>

renders:
Welcome to My Cool App *Matt*!

I want it to render:

Welcome to My Cool App <strong>Matt</strong>!

Thanks,

Matt



-- 
View this message in context: http://www.nabble.com/-s2--Is-it-possible-to-replace-supplement-i18n-resolution-logic--tf4214304.html#a12023712
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

Re: [s2] Is it possible to replace/supplement i18n resolution logic?

[Don Brown <do...@gmail.com>]

On 8/4/07, mraible <ma...@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

Re: [s2] Is it possible to replace/supplement i18n resolution logic?

[mraible <ma...@raibledesigns.com>]

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: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org