Re: Problem with BAction

Ok, here's what I'd like to recommend -

1. I think we need to create a method in BComponent called 
setEncoding(String enc)

2. calling getEncoding() would look to see if current encoding is set, 
if not return the parent encoding (which would iterate up the chain). If 
there is no encoding specified, "UTF-8" would be used. THis basically 
gives us the ability to set the encoding for an entire component 
structure, or just a subset.

3. we can then modify the renderers to take advantage of the encoding by 
querying the components.

I think this should pretty much solve Denny's problem.

Now I have an additional question - searching the code to see where else 
we reference encodings, I found this block of code in 
DefaultServletRequestWrapper:

//csc_110102.1_start - fix deprecation issues               
//csc_110402.1 - revert
//jrk_20030731.1_start - catch runtime exceptions in the decode() method
                    try {
                        queryString = 
java.net.URLDecoder.decode(queryString);
                    } catch (Exception e) {
                        logger.warn("failed to decode queryString, but 
allowing to continue", e);
                    }
//jrk_20030731.1_end
/*
                    try {
                        queryString = 
java.net.URLDecoder.decode(queryString, "UTF-8");
                    } catch (UnsupportedEncodingException e) {
                        System.out.println("Encoding Exception: "+e);
                        e.printStackTrace();
                    }
*/                   
//csc_110102.1_end

What I'm trying to understand here is this - it looks like we originally 
changed the code so as to specify UTF-8 (and thus not use the deprecated 
method). Then it looks like Jake changed it back to the default method 
(which is deprecated).

Does anyone remember why we did this???? I have a feeling there is a 
reason, and I'm reluctant to just change it back without understanding 
the implications...

THanks,
Christian

Denny Chambers wrote:

> Hi ALL
>
> I have run across a problem in the BAction class. In my Barracuda 
> webapp, I am sending all data to the browser as UTF-8, however my 
> local Operating System which is running my webapp server may be in 
> different character encoding formats, such as UTF-8, CP1252, 
> ISO-8859-1, etc. Now when my OS is in UTF-8, I don't have any real 
> problem sending extended characters (Characters outside of the ASCII 
> range, i.e. greater than decimal 127). But when I am in a different 
> code page like CP1252, I run into a problem sending extended 
> characters in URLs created by BLink/BAction. In the method 
> BAction.getAction(...) the parameter list is passed to the 
> java.net.URLEncoder.encode(String s). For one, this method had been 
> deprecated in favor of the java.net.URLEncoder.encode(String s, String 
> enc) method which allows you to encode the String based on a 
> particular character encoding format. Since Barracuda is using the 
> older encode method, which takes no encoding parameter, the encoding 
> is being done based on the JVM default encoding, which is set as a 
> system parameter "file.encoding". This means the non-ASCII characters 
> in my URL parameters are getting coded  using the byte sequence from 
> the default OS character encoding, instead of the UTF-8 character 
> encoding I want. It looks like the BAction classes need to allow for 
> an encoding parameter to be specified, so that URL encoding is done 
> properly.
>
> FYI - The W3C recommends that character encoding be done based on a 
> UTF-8 character set - 
> http://www.w3.org/TR/html40/appendix/notes.html#non-ascii-chars
>
>
> Thanks,
>


-- 

Christian

------------------------------------------------------------------------
Christian Cryder
Internet Architect, ATMReports.com <http://atmreports.com>
------------------------------------------------------------------------

/"Coffee? I could quit anytime, just not today"
http://seelifedifferently.blogspot.com/