Re: form encoding issues

[Ron Van den Branden]

 Hi Andre,

On 29/09/2010 12:01, Andre Juffer wrote:
Actually, Tomcat does, but Jetty does not (by default, UTF8). 
According to specification, servlet engine are suppose to decode using 
ISO-8859-1 by default.


I don't see any difference between both.




And lo: changing the  (over-eager?) container-encoding parameter in 
web.xml back to the default:


container-encoding
ISO-8859-1



Do I understand this correctly: you have encoded everything in UTF8, 
but to able to read your input fields (UTF8) you need to decode their 
value with ISO-8859-1 on the server?


Apparently: even Arabic text comes out fine with ISO-8859-1, not with 
UTF-8 (as I've mentioned in another reply on the ML).


I have had cases where the browser was encoding in ISO-8859-1 despite 
the presence of Content-type set to "text/html; charset=UTF-8" (it 
simply ignored the HTTP header value).


All my browsers interpret my test case as UTF-8 (with container-encoding 
set to ISO-8859-1)...


Kind regards,

Ron

-
To unsubscribe, e-mail: users-unsubscr...@cocoon.apache.org
For additional commands, e-mail: users-h...@cocoon.apache.org

Re: form encoding issues

[Ron Van den Branden]

 Hi Thomas,

I'm not much of an expert in encoding matters, and could indeed be happy 
with ISO-8859-1 instead of UTF-8.


However, testing with ISO-8859-1 set as container-encoding, even Arabic 
input is passed through correctly: ص (Arabic letter 'sad' - 
http://www.fileformat.info/info/unicode/char/0635/index.htm) comes out 
as it has been entered.


Does this mean that this (default) ISO-8859-1 container encoding does 
cater for UTF-8 correctly? Otherwise, would you mind expanding on your 
webapps/examples/WEB-INF/classes/filters/SetCharacterEncodingFilter.java 
suggestion (I'm not much of a Java expert, either ;-))?


OTOH, I don't see any difference between cocoon running in either Tomcat 
or the shipped Jetty.


Kind regards,

Ron

On 29/09/2010 12:11, Thomas Markus wrote:

thats right but you are bound to ISO-8895-1

we use UTF-8 in all stages with my comments.

regards
Thomas




-
To unsubscribe, e-mail: users-unsubscr...@cocoon.apache.org
For additional commands, e-mail: users-h...@cocoon.apache.org

Re: form encoding issues

[Ron Van den Branden]

 Hi again,

Thank you very much for the quick help; meanwhile I think I found an 
answer in a post on cocoon-dev: 
. There is stated that 
apparently (and counter-intuitively, IMO), 'request parameters are 
always decoded using ISO-8859-1 ',  and that consequently 
'container_encoding should always be ISO-8859-1 (unless you have a 
broken servlet container), and form_encoding should be the same one as 
on your serializer.'.


And lo: changing the  (over-eager?) container-encoding parameter in 
web.xml back to the default:


container-encoding
ISO-8859-1


...seems to do the trick!
(phew!)

(note: I found this info also at 
) 



Thanks anyway,

Ron

-
To unsubscribe, e-mail: users-unsubscr...@cocoon.apache.org
For additional commands, e-mail: users-h...@cocoon.apache.org

form encoding issues

[Ron Van den Branden]

 Hi,

I'm stumbling on a character encoding issue (cocoon-2.1.10) and really 
can't see why. Apparently, text input in a form is passed on in a wrong 
encoding. I've set Cocoon's default encoding in all thinkable places as 
UTF-8:


web.xml:


Cocoon


container-encoding
UTF-8


form-encoding
UTF-8




sitemap.xmap

name="xhtml"
pool-max="${xhtml-serializer.pool-max}" 
src="org.apache.cocoon.serialization.XMLSerializer">

-//W3C//DTD XHTML 1.0 Transitional//EN
http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd
UTF-8


Yet, when I execute following pipeline:









...with following minimal source files:

test.xml
===



test.xsl (which will mainly echo the previous input)
==

http://www.w3.org/1999/XSL/Transform"; 
version="2.0">












current input: 





Yet, entering a string with accented characters, like e.g. 'très 
annoying', this comes out as: 'très annoying'...
On the other hand, when entering the according URL 
(<http://localhost:/test?input=tr%C3%A8s+annoying>) directly, the 
characters are passed on correctly. Does anyone know how this can be fixed?


Any hints much appreciated!

Ron Van den Branden

-
To unsubscribe, e-mail: users-unsubscr...@cocoon.apache.org
For additional commands, e-mail: users-h...@cocoon.apache.org

Re: upgrading cocoon-2.1 to FOP-1.0

[Ron Van den Branden]

Hi Jasha,

Op 26/07/2010 15:47, Jasha Joachimsthal schreef:
Cool! Can you create an issue for this describing which dependencies 
you updated? I'll pick it up then.


Done: https://issues.apache.org/jira/browse/COCOON-2295. I hope this is 
all you need.


Kind regards,

Ron

-
To unsubscribe, e-mail: users-unsubscr...@cocoon.apache.org
For additional commands, e-mail: users-h...@cocoon.apache.org

Re: upgrading cocoon-2.1 to FOP-1.0

[Ron Van den Branden]

Hi again,

It seems I shouted too early (and for once I'm happy about that!). 
Apparently, it's my Firefox choking on the PDF output (probably 
memory-related, since restarting FF solved the issue). When I checked 
with Opera, all seemed to work perfectly! I can confirm following steps 
work for integrating FOP-1.0 in Cocoon-2.1.12-dev source code:


Op 26/07/2010 14:56, Ron Van den Branden schreef:

Thanks, but no success here... This is what I did:
-replace fop-related jars in %COCOON_HOME%\lib\* with updated 
versions from FOP-1.0 + added missing ones
-updated %COCOON_HOME%\lib\jars.xml to those new version numbers / 
jars

-rebuild Cocoon


Thanks again,

Ron

Re: upgrading cocoon-2.1 to FOP-1.0

[Ron Van den Branden]

Ok,

Op 26/07/2010 14:19, Jasha Joachimsthal schreef:
I have grabbed a fresh checkout, and it works perfectly with FOP-0.95. 
I have tried to replace the FOP-related jars in 
%COCOON_HOME%\build\webapp\WEB-INF\lib with those in the most recent 
FOP distribution, but then I'm hitting following error for the FOP 
sample files:



HTTP ERROR: 500

tried+to+access+class+org%2Eapache%2Exml%2Eserializer%2EExtendedContentHandler+from+class+org%2Eapache%2Exalan%2Etransformer%2ETransformerImpl

So apparently, more is needed to upgrade to FOP-1.0? Do you have
any clues (or plans for upgrading Cocoon-2.1.12-dev)? (By
extension, do you know of any release schedule for Cocoon-2.1.12?)


No bells ringing yet. Have you tried building Cocoon with the new FOP 
dependencies instead of replacing the jars in the build? Maybe they've 
modified some classes that will lead to  compilation errors.

There's no release schedule for 2.1.12 yet.


Thanks, but no success here... This is what I did:
-replace fop-related jars in %COCOON_HOME%\lib\* with updated 
versions from FOP-1.0 + added missing ones

-updated %COCOON_HOME%\lib\jars.xml to those new version numbers / jars
-rebuild Cocoon
For the FOP samples, this generates no PDF at all: an empty browser 
window, without errors.


I guess I'll have to be patient for a while...

Kind regards,

Ron

Re: upgrading cocoon-2.1 to FOP-1.0

[Ron Van den Branden]

Hi Jasha,

Ah, that's even more than I asked for ;-). Apologies, for one reason or 
another I missed the connection with Cocoon-2.1.12-dev. I remember 
having tried to build it some time ago, but it failed.


Op 26/07/2010 13:12, Jasha Joachimsthal schreef:


a few weeks ago, I have upgraded FOP to 0.95 in the 2.1 branch 
(2.1.12-dev). It seems that you've found the correct issue for it. Did 
you try to start from that version?


I have grabbed a fresh checkout, and it works perfectly with FOP-0.95. I 
have tried to replace the FOP-related jars in 
%COCOON_HOME%\build\webapp\WEB-INF\lib with those in the most recent FOP 
distribution, but then I'm hitting following error for the FOP sample files:


HTTP ERROR: 500 
tried+to+access+class+org%2Eapache%2Exml%2Eserializer%2EExtendedContentHandler+from+class+org%2Eapache%2Exalan%2Etransformer%2ETransformerImpl


So apparently, more is needed to upgrade to FOP-1.0? Do you have any 
clues (or plans for upgrading Cocoon-2.1.12-dev)? (By extension, do you 
know of any release schedule for Cocoon-2.1.12?)


Thanks for your help,
Kind regards,

Ron

-
To unsubscribe, e-mail: users-unsubscr...@cocoon.apache.org
For additional commands, e-mail: users-h...@cocoon.apache.org

upgrading cocoon-2.1 to FOP-1.0

[Ron Van den Branden]

Hi,

With the release of FOP-1.0, I would like to finally update my 
Cocoon-2.1 applications to this version. Apart from some scattered 
fragmentary instructions on some apache-related mailing lists, I 
couldn't find much information. I have tried instructions at:

-http://markmail.org/message/defvrey2nf7v63am
-https://issues.apache.org/jira/browse/COCOON-2289
...and found some files at 
https://svn.apache.org/repos/asf/forrest/trunk/plugins/org.apache.forrest.plugin.output.pdf/lib/


Unfortunately, I couldn't manage to get FOP-1.0 working in 
Cocoon-2.1.11. Is there someone out there who has managed to figure out 
the necessary steps, and would like to provide step-by-step instructions 
for upgrading FOP in Cocoon-2.1?


Any help much appreciated,

Ron

--
Ron Van den Branden
Wetenschappelijk Attaché
Centrum voor Teksteditie en Bronnenstudie (CTB)
Koninklijke Academie voor Nederlandse Taal- en Letterkunde (KANTL)
Koningstraat 18  B-9000 Gent
Tel: +32 9 265 93 53 / Fax: +32 9 265 93 49
E-mail : ron.vandenbran...@kantl.be
www.kantl.be/ctb


-
To unsubscribe, e-mail: users-unsubscr...@cocoon.apache.org
For additional commands, e-mail: users-h...@cocoon.apache.org

Re: aggregating duplicate parameters at sitemap level

[Ron Van den Branden]

Hi Jeroen,

Thanks a lot for this quick and helpful hint: I now manage to get an XML
representation of the request with the RequestGenerator. That's
excellent for XSL processing, but... I still don't see clearly how I can
integrate this in the pipeline (sorry - I take full account of my
ignorance).

Jeroen Reijn schreef:



In that case the only thing you need to do in your sitemap is change 
your generate part to an aggregate and you will probably have to 
change your xslt a bit and that would be it.



Do I understand you correctly by thinking that you'd aggregate both the
XML request representation (via RequestGenerator) and the requested XML
source (via another pipeline) into an XML structure for further
processing? Something like:

  

  
  
  
  


  


  

Then the question marks are unclear to me...

Just as a side note: I always discourage use-request-parameters, since 
it can give you problems when using caching pipelines.



What alternative do you suggest?

Thank you very much,

Ron Van den Branden




-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

aggregating duplicate parameters at sitemap level

[Ron Van den Branden]

Hi,

In my application, I have some HTML forms containing lists of checkbox 
inputs and multiple select boxes. This results in request URIs featuring 
duplicate parameter names:


e.g.: 
http://localhost:/myapp/processform.htm?par1=val1&par1=val2&par1=val3


If I pass these to my XSLT transformation using name="use-request-parameters" value="true"/>, only the first value (viz. 
"val1") ends up in my XSLT. This is a short sitemap.xmap snippet:


   
 
 
   
 
 
   

So far, I worked around this with client-side Javascript that would 
aggregate those values for the duplicate parameters into one string, so 
that only 1 "par1" parameter is passed through:


e.g.: http://localhost:/myapp/processform.htm?par1=val1%20val2%20val3

In revising my app (and bringing it closer to unobtrusive JS practice), 
however, I would like to free that vital part of its fuctionality (form 
submission) from this client-side Javascript dependency.


My question is: is there a way of aggregating duplicate parameters into 
one parameter at sitemap level? The scarce posts I came across on this 
list suggest that it *can* be done (e.g. 
http://marc.theaimsgroup.com/?l=xml-cocoon-users&m=113474098814411&w=2), 
but not exactly how... At least, I can't see a solution with my current 
cocoon knowledge (not much beyond simple pipeline concepts, ie. no 
flowscript, actions, XSP...).


I recognize this is not strictly a Cocoon problem (and apologize for 
off-topicality), but hope there may be a Cocoon solution?


Thanks for any reaction!

Ron Van den Branden


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]