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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-- Marc Portier http://outerthought.org/ Outerthought - Open Source, Java & XML Competence Support Center Read my weblog at http://blogs.cocoondev.org/mpo/ [EMAIL PROTECTED] [EMAIL PROTECTED]
--------------------------------------------------------------------- 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]
