I believe it is... just for some clarity here:
It may 'resist' because:
this information is stored in a mysql TEXT field.
Becuase mysql barfs all over 's I put it in like this:
description='<xsp:logic>java.net.URLEncoder.encode(<xsp-request:get-paramete
r name="description"/>)</xsp:logic>'
And I get it out by:
<xsp:logic>
String s = <esql:get-ascii column="description"/>;
String s = <esql:get-ascii column="description"/>;
try {
s=java.net.URLDecoder.decode(s);
} catch (Exception e) {}
</xsp:logic>
(carriage returns are encoded as %0D%0A at this point)
The rest of the app and transformations turn out normal.
ie, no regular xml transformations contain - only database selects.
esql maybe?
But because my cocoon.conf build contains them when I do a clean build, it
led me to believe xalan itself was the culprit. I wonder.. does woody change
any xalan settings?
JD
-----Original Message-----
From: Joerg Heinicke [mailto:[EMAIL PROTECTED]
Sent: Wednesday, November 12, 2003 2:29 PM
To: [EMAIL PROTECTED]
Subject: Re: Xalan Problem
On 12.11.2003 22:12, Tony Collen wrote:
>> Replace with "nothing" in the XSLT:
>> <xsl:value-of select="translate(text(), ' ', '')"/>
>
>
> Hmnm, yeah, but where's the actual problem coming from?
>
> Just curious,
>
> Tony
Don't know exactly, so let me guess:
The text typed into a textarea contains (line feed) and
(carriage return). When sending this to the server it is stored in which
form ever. Now if you work on this XML with XSLT I don't know why it's
still there. Isn't a line break simply replaced with in the XML
model? Why will the "resist"? Is it Xalan's fault?
Joerg
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]