Re: Problem with BAction

Christian,

So if I understand the changes correctly, I should be able to set the
encoding type when I create my BTemplate, then an BComponents added to
the BTemplate from the model should pick up the new encoding. Is that
correct?

Code Example:

Document page =
DefaultDOMLoader.getGlobalInstance().getDOM(MyPageHTML.class,
vc.getRequest().getLocale());

Node node = page.getElementById("bodyId");

BTemplate templateComp = new BTemplate();

templateComp.setEncoding("UTF-8");

templateComp.addModel(new MyPageModel(context));

templateComp.setView(new DefaultTemplateView(node));

try {

templateComp.render(new DefaultViewContext(context));

}

catch(RenderException re) {

re.printStackTrace();

}

catch(Exception ex) {

ex.printStackTrace();

}

So by calling templateComp.setEncoding("UTF-8");, I don't have to set
the encoding on each individual BAction object that is add to the
Template by the model. Right?

Denny

Christian Cryder wrote:

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,

--

Foo bar rama

Christian

----------

Christian Cryder

Internet Architect, ATMReports.com

----------

"Coffee? I could quit anytime, just not
today"

http://seelifedifferently.blogspot.com

--

Foo bar rama

Christian

----------

Christian Cryder

Internet Architect, ATMReports.com

----------

"Coffee? I could quit anytime, just not
today"

http://seelifedifferently.blogspot.com

--
=========================================================
Denny Chambers

Unix IS user friendly - it's just picky about it's friends.