Hey All, I sent out email on this a while back, and didn't get a whole lot of input. The idea behind this change is to make life easier for those dealing with charsets other than the default one for the container. It's now possible to specify the charset to use per-locale and the LocalePicker and StripesFilter cooperate to then set the right character encoding on both the request and response before any data is read or written.
The hope is that by specifying it once here, it will cut down on repitition in JSPs, and also ensure that request parameters are processed using the correct encoding. Would anyone like to volunteer to test this stuff out? -t On Jun 18, 2006, at 11:25 AM, Tim Fennell (JIRA) wrote: > [ 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 _______________________________________________ Stripes-development mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/stripes-development
