Stripes

<fmt:formatDate /> wrong locale when using Layouts and custom LocalePicker

Details

  • Type: Bug Bug
  • Status: Open Open
  • Priority: Major Major
  • Resolution: Unresolved
  • Affects Version/s: None
  • Fix Version/s: None
  • Component/s: Formatting
  • Labels:
    None
  • Environment:
    Win 7, Java 6, Resin 3.1.10

Description

Reading the Stripes documentation about localization:

<<
Secondly, you should rarely have a need to use the <fmt:setLocale.../> tag. Because of Stripes' strategy of using a filter and a request wrapper, all components in your application, including the JSTL tags, will always get the right locale when they call request.getLocale().
>>

Using the Layout template mechanism I cannot get <fmt:formatDate /> to use the locale returned by my custom LocalePicker - it seems to always use the browsers preferred locale.

If I include <fmt:setLocale value="${pageContext.request.locale}" /> on my page it works fine. But reading the above documentation makes me wonder why thats required?

Activity

Hide
Nikolaos added a comment - 11/Nov/10 1:27 PM

Is this really a "Major" bug? Sounds to me like a question on why something needs to be coded this way.

An alternative and IMHO much better solution is to do the following in your a BaseActionBean super class that your ActionBeans inherit from:

@SuppressWarnings("unused")
@Before(stages = { LifecycleStage.EventHandling })
private void init() {
HttpServletRequest request = this.context.getRequest();
Locale locale = request.getLocale();

// Load locale specific resource bundle
ResourceBundle bundle = StripesFilter.getConfiguration().getLocalizationBundleFactory().getFormFieldBundle(locale);

// Set resource bundle so that it can be directly used in JSPs
javax.servlet.jsp.jstl.core.Config.set(request.getSession(), Config.FMT_LOCALIZATION_CONTEXT,
new LocalizationContext(bundle, locale));

IIRC this came from Freddy Daoud's book ... .

In any event, I think this bug can be marked closed as it is not an issue.

--Nikolaos

Show
Nikolaos added a comment - 11/Nov/10 1:27 PM Is this really a "Major" bug? Sounds to me like a question on why something needs to be coded this way. An alternative and IMHO much better solution is to do the following in your a BaseActionBean super class that your ActionBeans inherit from: @SuppressWarnings("unused") @Before(stages = { LifecycleStage.EventHandling }) private void init() { HttpServletRequest request = this.context.getRequest(); Locale locale = request.getLocale(); // Load locale specific resource bundle ResourceBundle bundle = StripesFilter.getConfiguration().getLocalizationBundleFactory().getFormFieldBundle(locale); // Set resource bundle so that it can be directly used in JSPs javax.servlet.jsp.jstl.core.Config.set(request.getSession(), Config.FMT_LOCALIZATION_CONTEXT, new LocalizationContext(bundle, locale)); IIRC this came from Freddy Daoud's book ... . In any event, I think this bug can be marked closed as it is not an issue. --Nikolaos
Hide
Christian Yttesen added a comment - 11/Nov/10 2:21 PM

Well - I agree its not a major bug - I simply got the impression (from reading the documentation) that I shouldn't worry about the obtaining the correct locale when using JSTL. Perhaps a note in the documentation about using templates and a hint to your implementation.

Show
Christian Yttesen added a comment - 11/Nov/10 2:21 PM Well - I agree its not a major bug - I simply got the impression (from reading the documentation) that I shouldn't worry about the obtaining the correct locale when using JSTL. Perhaps a note in the documentation about using templates and a hint to your implementation.
Hide
Iwao AVE! added a comment - 02/Dec/10 10:24 AM

Custom locale picker should work as documented.
Could you post a minimum webapp to reproduce the problem?

Show
Iwao AVE! added a comment - 02/Dec/10 10:24 AM Custom locale picker should work as documented. Could you post a minimum webapp to reproduce the problem?
Hide
Ben Gunter added a comment - 29/Dec/10 12:31 PM

Since there seems to be a good bit of disagreement on the exact nature of the problem and since Christian's comments indicate this has something to do with the layout tags, I'm unscheduling this issue until we can get more information on exactly what's happening. The layout tags have undergone major changes since 1.5.3, and a lot of problems related to the old layout code have been fixed as a side effect of those changes. I would like to know if this is still a problem in 1.5.4 and the soon-to-be-released 1.5.5.

Show
Ben Gunter added a comment - 29/Dec/10 12:31 PM Since there seems to be a good bit of disagreement on the exact nature of the problem and since Christian's comments indicate this has something to do with the layout tags, I'm unscheduling this issue until we can get more information on exactly what's happening. The layout tags have undergone major changes since 1.5.3, and a lot of problems related to the old layout code have been fixed as a side effect of those changes. I would like to know if this is still a problem in 1.5.4 and the soon-to-be-released 1.5.5.

People

Vote (0)
Watch (0)

Dates

  • Created:
    11/May/10 4:08 AM
    Updated:
    29/Dec/10 12:31 PM