Stripes's LocalizationTag Strategy is Inconsistent with JSTL Tag Strategy for
Locating and Resource Bundle
----------------------------------------------------------------------------------------------------------
Key: STS-552
URL: http://www.stripesframework.org/jira/browse/STS-552
Project: Stripes
Issue Type: Bug
Reporter: Wendy Cameron
The strategy for locating a resource bundle through the following class that is
used through out the Stripes tags, may be flawed from jsp point of view.
net.sourceforge.stripes.localizationDefaultLocalizationBundleFactory
This factory for stripes always gets the bundle using one of the following two
methods:
ResourceBundle.getBundle(this.errorBundleName);
ResourceBundle.getBundle(this.errorBundleName, locale);
ResourceBundle.getBundle(this.fieldBundleName);
ResourceBundle.getBundle(this.fieldBundleName, locale);
However consider the following scenerio:
{code}
<fmt:bundle basename="com.orchestral.common.translation.client.Configuration">
<stripes:select name="selectedToy">
<stripes:options-collection
collection="${actionBean.list}" value="id" label="name" />
</stripes:select>
</fmt:bundle>
{code}
I want the resource bundle to be used to be the one currently in scope, tags
need to check for an tag ancestor that from fmt:bundle and use the bundle from
there.
If no ancestor fmt:bundle tag then the tag should use the bundle in the page
context which should already have been resolved based upon the locale.
However stripes circumvents this to provide an error bundle and a fieldName
bundle. Which cannot be scoped, this is in contravention of the intention of
the fmt:bundle tag, and the pattern laid out in most jstl tags.
The stragey employed by most jstl tags is:
{code:java}
Tag t = findAncestorWithClass(this, BundleSupport.class);
if (t != null) {
// use resource bundle from parent <bundle> tag
BundleSupport parent = (BundleSupport) t;
locCtxt = parent.getLocalizationContext();
prefix = parent.getPrefix();
} else {
locCtxt = BundleSupport.getLocalizationContext(pageContext);
}
{code}
This is an issue for us because we want different bundle behavior for
configuration text verses standard text. We have the scenario where we get
back from the data base a label, that then needs to be translated, we allow
users to set up english phrases and provide french and spanish translations for
these, these translations are looked up using the label. So essentially we
have some unique translation requirements, and we dont want to rewrite all the
stipes tags providing two sets and creating confusion. However it is
increasing looking more and more likely that we will have to rewrite all these
tags to do something more sensible.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://www.stripesframework.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
-------------------------------------------------------------------------
This SF.net email is sponsored by the 2008 JavaOne(SM) Conference
Don't miss this year's exciting event. There's still time to save $100.
Use priority code J8TL2D2.
http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone
_______________________________________________
Stripes-development mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/stripes-development
