mistake in cocoon3.0 userguide ?

Re: mistake in cocoon3.0 userguide ?

Robby Pelssers wrote:
> Hi,
> 
>  
> 
> First of all nice to see some usefull documentation for Cocoon3.0.
> 
>  
> 
> The following underlined snippet seems wrong to me:
> 
>  
> 
> A pipeline works based on two fundamental concepts:
> 
> ·         The first component of a pipeline is of type
> |org.apache.cocoon.pipeline.component.Starter|. The last component is of
> type |org.apache.cocoon.pipeline.component.Finisher|.
> 
> ·         In order to link components with each other, _the first has to
> be a _|_org.apache.cocoon.pipeline.component.Finisher_|_, the latter
> _|_org.apache.cocoon.pipeline.component.Producer_|.
> 
> Shouldn’t that be
> 
>  
> 
> A pipeline works based on two fundamental concepts:
> 
> ·         The first component of a pipeline is of type
> |org.apache.cocoon.pipeline.component.Starter|. The last component is of
> type |org.apache.cocoon.pipeline.component.Finisher|.
> 
> ·         In order to link components with each other, _the first has to
> be a _|_org.apache.cocoon.pipeline.component.Producer_|_, the latter
> _|_org.apache.cocoon.pipeline.component.Consumer_|.

I fixed it in SVN. Thank you very much!

--

-- 
Reinhard Pötz                           Managing Director, {Indoqa} GmbH
                         http://www.indoqa.com/en/people/reinhard.poetz/

Member of the Apache Software Foundation
Apache Cocoon Committer, PMC member                  reinhard <at> apache.org
________________________________________________________________________

change in behavior of Forms Aggregate field?

Hi There,

My application uses the aggregatefield widget in Cocoon Forms.

Till Cocoon 2.1.8, I used to be able to add new fields at the END of the 
aggregate and still see data in the older fields before the new fields.  
This was very convenient for the end user.

With migration to 2.1.11, it appears that when new fields are added to 
the aggregate, then the old data is no longer visible in the older fields?

Does this make sense?  Is there anyway I can turn on debugging on the 
"split" of the aggregate to see what is happening? 

I am not able to follow the documentation that implies that adding the 
element failmessage as shown below (from the cocoon documentation)

  <fd:split pattern="...">
    <fd:map group="..." field="..."/>
    [... more fd:map elements ...]
    <fd:failmessage>...</fd:failmessage>
  </fd:split>

 will provide info. on why the split failed--I added the 

    <fd:failmessage>...</fd:failmessage>

but I am not seeing the info.

thx.
Paul

Not escaping html-code in Cocoon (second post)

Re: Not escaping html-code in Cocoon (second post)

Re: Not escaping html-code in Cocoon (second post)

On Jan 7, 2010, at 10:04 AM, Derek Hohls wrote:

> This seems relevant:
> http://www.5341.com/msg/102900.html

No, it is not.

Now this page is much closer to home.

  http://wiki.apache.org/cocoon/XSPUtil

Vadim

> >>> On 2010/01/07 at 12:20, in message
<2ad029481001070220g52ffd5a4hae76f8b0f54d6c23 <at> mail.gmail.com>, Stefaan Somers
<stefaan.somers <at> gmail.com> wrote:
> I want to insert HTML-code coming from a database into one of my XSP-pages. But Cocoon immediateley
escapes those characters so they are not parsed by my browser. How can I avoid this??

character encoding of a HttpServletRequest

Hi,

HttpServletRequest looks 'imperfect':
Cocoon 3, alpha 2.
A generator accesses the HttpServletRequest in the setup method:

request = HttpContextHelper.getRequest(parameters);
text = request.getParameter("tekst");

The pages, including forms are ecoded in utf-8.
The String 'text' is strange: the original content (utf-8) is encoded
once again:
if the string on the form was one character, say 'é', the string has a
length of 4 bytes. It is the result of utf-8 encoding the two byte
character coming from the client. So, a second conversion is happening.

Now:
new String(request.getParameter("text").getBytes("ISO-8859-1")) works
fine.

Where should this be corrected?

Cheers,
Jos

Re: character encoding of a HttpServletRequest

This is not a specific cocoon issue, I believe. It probably has to do
with Tomcat 5.5.27.
request.setCharacterEncoding simply does not work; it does not change a
thing.
request.getCharacterEncoding returns nothing.

Best,
Jos

On Sat, 2010-01-09 at 08:01 +0100, Jos Snellings wrote:
> Hi,
> 
> HttpServletRequest looks 'imperfect':
> Cocoon 3, alpha 2.
> A generator accesses the HttpServletRequest in the setup method:
> 
> request = HttpContextHelper.getRequest(parameters);
> text = request.getParameter("tekst");
> 
> The pages, including forms are ecoded in utf-8.
> The String 'text' is strange: the original content (utf-8) is encoded
> once again:
> if the string on the form was one character, say 'é', the string has a
> length of 4 bytes. It is the result of utf-8 encoding the two byte
> character coming from the client. So, a second conversion is happening.
> 
> Now:
> new String(request.getParameter("text").getBytes("ISO-8859-1")) works
> fine.
> 
> Where should this be corrected?
> 
> Cheers,
> Jos
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe <at> cocoon.apache.org
> For additional commands, e-mail: users-help <at> cocoon.apache.org
> 
> 

File upload without "full" form submit.

Hi.

I have form with 3 repeaters, one contains standard text input widgets, 
and the next two contain file upload widgets. User can add file inputs, 
select files, and press submit button which will submit form and 
redirect from form page.

I would like to add separate submit button to each upload widget in 
repeater and upload each file without submitting whole form and redirect 
from page.

Is it possible ? Can anyone give mi some tips how to do it ?

Regards,
Tomek Piechowicz

Re: character encoding of a HttpServletRequest