Re: Problem with BAction

I have checked this change into place:

csc_041805_1 - Implemented support for configurable encoding.

               1. added the following methods to BComponent 
setEncoding(String enc), getEncoding(),
               encodeStr(String s), decodeStr(String s)

               2. calling getEncoding() will 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,
               BComponent.DEFAULT_ENCODING will be used. Note that the 
encode/decodeStr methods are
               protected, and they eat exceptions - if a problem is 
encountered we try alternate encodings
               or use the default.

               3. BAction can now take advantage of this when encoding 
params. Not sure if we need to make use
               of this elsewhere as well.
              
               4. To configure the default encodings, you can use the 
object repository assembler to
               set BComponent.DEFAULT_ENCODING or 
DefaultServletRequestWrapper.DEFAULT_ENCODING

Denny, could you take a look and see if this works for you? Holler if 
questions...

Christian



Christian Cryder wrote:

> 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/
>


-- 

Christian

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

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