Mailing-List: contact users-help@cocoon.apache.org; run by ezmlm
Precedence: bulk
Reply-To: users@cocoon.apache.org
Received-SPF: pass (athena.apache.org: domain of solprovider@gmail.com
 designates 72.14.220.158 as permitted sender)
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=beta;
        h=message-id:date:from:sender:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references:x-google-sender-auth;
        b=OZRco8Jbe4b+cqAAncwqLeoakuctu1l5bUTVuEyJYmj0i+UXz2c7iZ4ob8KztR4ZLqDqFPqmbkrL51g7MX8lm/ECPgtB/7C465D9K1UwKU3tnANOLrn55Rnjs7/ugrw8QxAwICtBRhQEa7lKyJDRvA03WLW3RhTMo+J7vIZsuLE=
Message-ID: <dfe834320803311002y6ed7aeccvbf4b477d54362d53@mail.gmail.com>
Date: Mon, 31 Mar 2008 13:02:57 -0400
From: solprovider@apache.org
Sender: solprovider@gmail.com
To: users@cocoon.apache.org
Subject: Re: Redirect to GET, strange bug
In-Reply-To: <33A582DC-CFBD-4E88-ABFF-0F990BFC75DB@linux.it>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
References: <33A582DC-CFBD-4E88-ABFF-0F990BFC75DB@linux.it>

On 3/31/08, Tobia Conforto <tobia.conforto@linux.it> wrote:
>  I'm trying to implement in Cocoon a somewhat standard web behaviour: at the
> end of a form (final POST request, form fully validated, etc.) I'd like to
> redirect the user to a GET request before showing him the final 'Thank you'
> page.
>
>  This is often done in web programming, so that in case the user reloads the
> result page, he will just reload the page itself, and not execute the form
> logic twice.  The browsers use this interpretation too, by showing the user
> a warning "The form action will be executed again if you reload. Are you
> sure? Yes/No" when you try to reload a POST page.
>
>  I thought this would be easy to accomplish with continuations, but I'm
> hitting a strange bug.  This is the utility function I'm calling from my
> flows, AFTER the form has been processed (DB inserts, emails sent, etc),
> just BEFORE doing the sendPage() with the result page:
>
>  function redirectToGet() {
>         var done = false;
>         var cont = cocoon.createWebContinuation();
>         if (! done) {
>                 done = true;
>                 cocoon.redirectTo('/cont=' + cont.id, true);
>                 cocoon.exit();
>         }
>  }
>
>  The problem is:
>  - if I leave out the cocoon.exit(), I get:
>  IllegalStateException: Pipeline has already been processed for this request
>
>  - if I put the cocoon.exit() as shown, I get:
>  ProcessingException: Attempted to process incomplete pipeline
>
>  What gives?
>  I'm using Cocoon 2.1.10
>  Tobia

FYI: Cocoon's redirects usually escape from the current processing.
The redirect is sent to the browser, but the request may not have been
processed.  That does not appear to be what you need.

The Redirect from submitting a Form cannot be internal to Cocoon (or
any web engine).  The Form is received, processed, and sends a
response.  That response can send a browser redirect (META REFRESH or
JS location='') so the submitted Form is not the last page in the
browser.  If the browser's back button is used, the browser tries to
open the redirecting page and forces the browser forward again.  This
is common and a bad process -- every browser's Back button allows
returning more than one page back and the user can still resubmit the
Form by moving back more than one page.

The better solution is to use a hidden field containing a unique key
on the Form.  When processing the form, return a "duplicate request"
message (which should contain a link to the original form if someone
might want to send the Form more than once) if the key has already
been submitted.  This is good for applications where resubmitting a
request can cause damage (such as placing an order where two submits
doubles the financial obligation), but is annoying when damage is not
possible (such as sending a comment or request for assistance.)

solprovider

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