[ http://mc4j.org/jira/browse/STS-210?page=all ]
Tim Fennell resolved STS-210:
-----------------------------
Resolution: Fixed
This has been implemented pretty much as described above. The list of Locales
can now optionally specify character encodings, e.g.:
en_US,ja:Shift_JIS,en_UK:UTF-8
The encoding is entirely optional and can be specified for zero, some or all
locales. If not specified, no calls to setCharacterEncoding are made.
Additionally it turns out that at least for JSP, the content type is
automatically set to the default of "text/html" or "text/xml" depending on the
type of JSP being used, so the character encoding gets communicated without
Stripes having to mess with the content type setting.
> Improved locale-based character-encoding handling
> -------------------------------------------------
>
> Key: STS-210
> URL: http://mc4j.org/jira/browse/STS-210
> Project: Stripes
> Type: Improvement
> Components: ActionBean Dispatching
> Reporter: Tim Fennell
> Assignee: Tim Fennell
> Fix For: Release 1.4
>
> The way I figure it there are a few parts to this:
> 1. Ensure that the correct locale is used for number/date parsing and
> for error messages (done pre-1.4)
> 2. Ensure that the correct locale is available for other things
> downstream (done pre-1.4)
> 3. Ensure that the request is parsed using the correct *character
> encoding* (not done)
> 4. Ensure that the response is sent in the correct character encoding
> (not done)
> 5. Ensure that the browser is made aware of the response encoding
> Right now Stripes has a LocalePicker component that is responsible for
> deciding what locale to use when processing and type converting values in the
> request, when formatting values in pages, etc. To make life easier Stripes
> wrap the request and ensures that all subsequent calls to request.getLocale()
> return the correct locale.
> Stripes does *not* call Response.setLocale(). This is probably the first
> step in improving things. A little reading shows that the Servlet 2.4
> specification supports a new stanza in the web.xml file to map locales to
> character encodings. For example:
> <locale-encoding-mapping-list>
> <locale-encoding-mapping>
> <locale>tr_TR</locale>
> <encoding>UTF-8</encoding>
> </locale-encoding-mapping>
> </locale-encoding-mapping-list>
> In this case, when a call is made to HttpServletResponse.setLocale(tr_TR),
> the container will ensure that the response writer uses the UTR-8 encoding.
> What it doesn't do is set the character encoding for the HttpServletRequest,
> and therefore doesn't affect the character translation of text in the
> request. Nor, unfortunately does the specification provide programmatic
> access to this mapping information. Theoretically one could get the web.xml
> as a resource and parse it, but that's a lot of work :p
> So here's what I'm thinking. Where you currently specify a list of Locales
> in the web.xml for Stripes to use (yes, this is optional), we'd extend the
> format a little bit to allow the specification of a character encoding also.
> E.g.:
> <init-param>
> <param-name>LocalePicker.Locales</param-name>
> <param-value>en_US,tr_TR:UTF-8,ja:Shift_JIS</param-value>
> </init-param>
> I.e. locale:character_encoding. If the encoding isn't specified then let the
> container decide what is appropriate. This would allow Stripes to call
> HttpServletResponse.setCharacterEncoding(encoding) after calling
> HttpServletResponse.setLocale(locale), and effectively tackle #4 above.
> This also would allow Stripes to call
> HttpServletRequest.setCharacterEncoding(encoding) *before* anything is read
> from the request, ensuring that the the content is parsed in the specified
> encoding. But is that always going to be correct? If not, is there any way
> to determine programmatically the correct encoding to parse the request with?
> If this'd work (at least more often than doing nothing), it's help with #3.
> Tackling #5 is a bit trickier since the communication of character encoding
> is done through the Content-Type http header, which takes the form:
> Content-Type: text/html;encoding=UTF-8
> If a content type is not set, then the this header isn't sent even if a
> character encoding is set. So the only solution I can think of here that
> doesn't require a lot of repetition is to 1) have a new init/config param,
> perhaps 'Stripes.DefaultContentType' that would specify the default content
> type that would be set on all responses. If not specified it could default
> to "text/html". This would solve #5. It should be noted that setContentType
> can be called repeatedly, so this can always be overridden by downstream code
> or JSPs.
> So my question to those of you developing localized applications, how much of
> this would be helpful? Would the ideas outlined above at least improve
> things in the majority of cases without getting in the way or making anything
> else more difficult? Are there alternate solutions that would work better?
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://mc4j.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
_______________________________________________
Stripes-development mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/stripes-development
