You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@cocoon.apache.org by Marc Portier <mp...@outerthought.org> on 2004/03/27 00:25:54 UTC
Re: Continuations in Redirections
I think this could work with the infamous
'continuation-id-as-hidden-request-param' approach
(it was in Sylvain's presentation at the last Cocoon Gettogether)
try the following:
1/ let the form submit to the same uri:
<form action="" method="POST" />
2/ add the continuation-id as a
<input type="hidden" name="continuation-id" value="9837491871342" />
depending on what you use for templating-formhandling you achieve this
with one of
- cforms: <ft:continuation-id>
- xslt: parameter filled in by the FlowContinuationModule (scratchpad block)
- jx: #{$cocoon/continuation/id}
3/ adjust your sitemap to handle both start-function and continuations
under the same URI by selecting on GET/POST
<map:match pattern="uri-pointing-to-functionX">
<map:select type="method">
<!-- GET : start the flow for this screen -->
<map:when test="GET">
<map:call function="X"/>
</map:when>
<!-- POST (form submission) : continue the flow -->
<map:when test="POST">
<map:call continuation="{request-param:continuation-id}"/>
</map:when>
</map:select>
</map:match>
like this, the referer should keep on pointing to the same URL, which
when applied in the GET form just starts the flowscript again
(well, I haven't tried above but I can't see a reason why it shouldn't
just work)
oh, even before the ack that above is working or not:
this approach will REQUIRE that your script gets used in this setup, you
should clearly indicate (comment) that the more common *.continue
approach is not to be used
HTH,
-marc=
leo leonid wrote:
> Hi all,
>
> For a dynamic Site with lots of customization I had the following in mind:
>
> 1. User must not be redirected when/after changing some settings
> 2. User may change settings anywhere and anytime he wants to.
> 2. Changes are applied immediately. (no confirm, or reload)
>
> I reached all these objectives with the following lines of flowscript.
> This makes the user transparently reentering his current page, but with
> the new settings already applied.
>
> function setUserLanguage() {
> saveToCustomSettings(cocoon.request.get("language");
> cocoon.redirectTo(cocoon.request.getHeader("referer"));
> }
>
> Since I consequently use POST to pass my application data, this looks
> like a very simple solution, *but* only as long as you don't have to
> deal with continuations. At this continuations behave quite different.
> The one I obtain by referer is not the one I expected, and may cause
> data being resubmitted.
>
> Im sure there must be a solution, probably you can handle this with
> continuations even more exactly, but I need some hints...
>
> /leo
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
> For additional commands, e-mail: users-help@cocoon.apache.org
>
--
Marc Portier http://outerthought.org/
Outerthought - Open Source, Java & XML Competence Support Center
Read my weblog at http://blogs.cocoondev.org/mpo/
mpo@outerthought.org mpo@apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org
Re: Continuations in Redirections
Posted by leo leonid <te...@leonid.de>.
Many thanks for this inspiration, it helped me a lot, even though I
dismissed it meanwhile. Your approach solved all those problems
concerning unwanted submissions, and it was simple enough, so I was
very content with it, first, however, watching it working a while, I
noticed some shortcomings:
1. Increase of browser alerts, asking the user if he wants to repost
all data, when navigating back and forth through the screens.
2. Whereas at another place when going (browser) back for
correcting/changing some form data, no warnings, but all changes are
discarded finally.
3. If there is a sequence of long and complex continuations, then it
might be viewed as brute, if you just reset the whole procedure and
push the user back to the start again.
Yet another experience showing me my needs, namely means to control
form processing in respect of 1/back-steps, 2/redisplaying,
3/proceeding.
Yesterday I thoroughly searched the docs + wiki + lists for this. The
surprising result is that it's already there! at least parts of it,
hard to guess it's status. The largest source of available information
is most likely this thread by Chris, Silvain and Vadim from January:
http://marc.theaimsgroup.com/?t=107481967600004&r=1&w=2
I finally decided to stop wasting time with further unpromising
searching for more docs or even samples, and just started using it. I
scattered some cocoon.createWebContinuation() all over my flow
functions, mainly as separator of diverse showForm() functions which
they tie together. (still v1)
With ${cocoon.continuation.previousBookmark.id} I get the bookmarks ID,
if available, to pass it to my setUserLanguage() function, for
redirection, otherwise I still use referer. Everything worked
instantly, even though its probably a bad usage.
I'd really be happy if someone comes up with some snippets etc...
There are lots of questions... one is
Are there any news about this issue?
>> The id passed to <map:call> would include an indicator of whether
>> handleContinuation() should select the bookmark or the submit
>> continuation.
Thanks
/leo
On Mar 27, 2004, at 12:25 AM, Marc Portier wrote:
> I think this could work with the infamous
> 'continuation-id-as-hidden-request-param' approach
>
> (it was in Sylvain's presentation at the last Cocoon Gettogether)
>
> try the following:
> 1/ let the form submit to the same uri:
> <form action="" method="POST" />
>
> 2/ add the continuation-id as a
> <input type="hidden" name="continuation-id" value="9837491871342" />
>
> depending on what you use for templating-formhandling you achieve this
> with one of
> - cforms: <ft:continuation-id>
> - xslt: parameter filled in by the FlowContinuationModule (scratchpad
> block)
> - jx: #{$cocoon/continuation/id}
>
> 3/ adjust your sitemap to handle both start-function and continuations
> under the same URI by selecting on GET/POST
>
> <map:match pattern="uri-pointing-to-functionX">
> <map:select type="method">
> <!-- GET : start the flow for this screen -->
> <map:when test="GET">
> <map:call function="X"/>
> </map:when>
> <!-- POST (form submission) : continue the flow -->
> <map:when test="POST">
> <map:call continuation="{request-param:continuation-id}"/>
> </map:when>
> </map:select>
> </map:match>
>
> like this, the referer should keep on pointing to the same URL, which
> when applied in the GET form just starts the flowscript again
>
> (well, I haven't tried above but I can't see a reason why it shouldn't
> just work)
>
> oh, even before the ack that above is working or not:
> this approach will REQUIRE that your script gets used in this setup,
> you should clearly indicate (comment) that the more common *.continue
> approach is not to be used
>
>
> HTH,
> -marc=
>
> leo leonid wrote:
>
>> Hi all,
>> For a dynamic Site with lots of customization I had the following in
>> mind:
>> 1. User must not be redirected when/after changing some settings
>> 2. User may change settings anywhere and anytime he wants to.
>> 2. Changes are applied immediately. (no confirm, or reload)
>> I reached all these objectives with the following lines of flowscript.
>> This makes the user transparently reentering his current page, but
>> with the new settings already applied.
>> function setUserLanguage() {
>> saveToCustomSettings(cocoon.request.get("language");
>> cocoon.redirectTo(cocoon.request.getHeader("referer"));
>> }
>> Since I consequently use POST to pass my application data, this looks
>> like a very simple solution, *but* only as long as you don't have to
>> deal with continuations. At this continuations behave quite
>> different. The one I obtain by referer is not the one I expected, and
>> may cause data being resubmitted.
>> Im sure there must be a solution, probably you can handle this with
>> continuations even more exactly, but I need some hints...
>> /leo
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
>> For additional commands, e-mail: users-help@cocoon.apache.org
>
> --
> Marc Portier http://outerthought.org/
> Outerthought - Open Source, Java & XML Competence Support Center
> Read my weblog at http://blogs.cocoondev.org/mpo/
> mpo@outerthought.org mpo@apache.org
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
> For additional commands, e-mail: users-help@cocoon.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org