Maybe the problem is not that sendPage what is the last, but the second last..

pseudo code:

line 1: // starts
line 2: sendPageAndWait("firstpage");
line 3: // do stuff
line 4: sendPageAndWait("lastpage");

and whn submitting form on firstpage it has continueid to line 3
when pushing reload on lastpage, it goes back to line 3 and starts executing from there.


So we should be able to cancel every continuation.

I don't use woody.

- Joose

16.4.2004 kello 12:47, Leon Widdershoven kirjoitti:

On my system, pressing reload on:
http://localhost:4255/cocoon/apps/importSpreadsheet/ 300872716f0382177d6d4e4a15234783622c7d5d.continue
yields a
The continuation ID 300872716f0382177d6d4e4a15234783622c7d5d is invalid.
(cocoon 2.1.4).


Snippet from function:
function conversie() {

    var form = new Form("forms/conversie-model.xml");
    var k = form.showForm("conversie-display-pipeline");
    k.invalidate();

var name = form.getWidget( "upload" ).getValue();

    cocoon.session.setAttribute( fileToConvertKey, name );
    cocoon.sendPage("conversie-success-pipeline.jx",
        {}
    );
}

Snippets from sitemap:
<map:match pattern="*.continue">
        <map:call continuation="{1}"/>
</map:match>
<map:match pattern="*-display-pipeline">
        <map:generate src="forms/{1}-template.xml"/>
        <map:transform type="woody"/>
        <map:transform src="stylesheets/intranet.xsl"/>
        <map:serialize/>
</map:match>
<map:match pattern="*-success-pipeline.jx">
        <map:generate src="forms/{1}-result.xml" type="jx">
                <map:parameter name="lenient-xpath" value="true"/>
        </map:generate>
        <map:transform src="stylesheets/intranet.xsl"/>
        <map:serialize/>
</map:match>

The only real difference might be the k.invalidate() on the
form... (if you use woody forms).

Leon


Joose Vettenranta wrote:
Nope, does not work.
I changed it to cocoon.sendPageAndWait ("Finalpage", {"foo": bar stuff is here}, 1);
-> reload -> it still is loading that finalpage (running SQL-queries etc)
Also tried cocoon.sendPageAndWait ("Finalpage", {foo...}, null, 1);
-> reload -> it still is loading that finalpage
It's very important that those SQL-queries are not done again -> killing this flow will do that.
Cache is not a problem, because cache won't do those SQL-queries...
- Joose
16.4.2004 kello 11:48, Leon Widdershoven kirjoitti:
use sendPageAndWait(...., timeToLive) with a very short
time to live?

And make sure there's no proxy/cache somewhere of course:)

Leon

Joose Vettenranta wrote:

16.4.2004 kello 10:56, Leon Widdershoven kirjoitti:
Hei,

As far as I know you need not invalidate pages used with sendPageAndWait(),
only the bookmarks you set.

Well, it still seems to work.
Last page has cocoon.sendPage ();
if I push reload in browser, it still loads last page again -> shit happens =). This is something I don't want to happen.
- Joose
--
"Always remember that you are unique, just like everyone else!"
* http://iki.fi/joose/ * [EMAIL PROTECTED] * +358 44 561 0270 *
-------------------------------------------------------------------- -
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]


--
"Always remember that you are unique, just like everyone else!"
* http://iki.fi/joose/ * [EMAIL PROTECTED] * +358 44 561 0270 *
---------------------------------------------------------------------
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]


--
"Always remember that you are unique, just like everyone else!"
* http://iki.fi/joose/ * [EMAIL PROTECTED] * +358 44 561 0270 *


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



Reply via email to