[ http://mc4j.org/jira/browse/STS-210?page=all ]
Tim Fennell updated STS-210:
----------------------------
Comment: was deleted
> Improved locale-based character-encoding handling
> -------------------------------------------------
>
> Key: STS-210
> URL: http://mc4j.org/jira/browse/STS-210
> Project: Stripes
> Issue Type: Improvement
> Components: ActionBean Dispatching
> Reporter: Tim Fennell
> Assigned To: 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
-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
Stripes-development mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/stripes-development
