You basically have a tree of continuations on the server side. You don't have to "pop the stack" to show a particular leave.
Right, I should have made it clearer, even for our case where we don't have a tree, I don't think this is worth doing...
You always have a possible tree. This does not depend on how you define the flow but how the user accesses you application!
So if IIUC you then can store a continuationid per page.
But that's not enough: you can have n continuationids per page! Maybe not much likely to happen very often - but not totally far out.
Yes, I can see that for some applications this might be useful.
As I pointed out above - this does not depend on the application. Imagine you have a simple flow. 3 Pages
a -> b -> c
This still can become a tree as soon as the user clones his browser on b and goes on in both browsers
a:c1 -> b:c2 -> c:c3
|
+----> c:c4Or when he goes back from c to b and then to c again.
> However, for
us a page is a page is a page and we do not need separate state tracking for multiple instances of them.
Well, if you wanna deal with the consequences... It's a bit like you store your form instance inside the session under a single key. Which
is basically an anti-pattern.
This works, I tested it yesterday, but I've since
Did you try when you duplicate you browser window?
No, but I don't think it should be an issue, in memory cookies are cloned at least for IE, but I've already trashed the code to work on the new solution.
With this sollution you will only see the latest continuation associated with that particular page and cannot show any other.
Hm... would work for the back-button thing ...but not for browser cloning.
Hmmmmmm.....
You're still waiting... Basically as Sylvain suggests to Vadim in another thread I'm implementing a ContinuationsManager that manages the continuations in sessions. This does, as Sylvain hints, also solve the problems of blowing away the continuations. I'm down to one issue:
Sure ...but I don't see a connection here
<snip/>
Both. In our system, as I've written before, all pages are forms and
can potentially be posted back to the server. However, 90% of the time
the user simply brings the data up and then does a GET on another page.
We can have 100's of instances of the same page being viewed at the same
time and I want to generate them all from the same Cocoon cache.
Well, this would only work if the form is not pre-filled or is filled the same way for all users. And only for the first view! After that what comes out of the pipeline is always different! ...and IMO cannot be cached.
Are your forms always filled the same?
For flow to work the Cocoon cache key does not have to be unique per page, the continuation has to be uniquely determined for a given page.
Only if the flow does not hand variables to the page!
<snip/>
There are definitely trade offs to be made here. We have a little better control over the situation than some people might since we running an Intranet application where we can simply say, sorry, X is not support (where X might be cloning an instance of a browser in this case).
I see
cheers -- Torsten
