Torsten Curdt <[EMAIL PROTECTED]> writes: > > >>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!
No, it depends on how the application treats the pages. If they can't have unique instances for a given page then there is no tree. > >>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:c4 > > Or when he goes back from c to b and then to c again. Yes, but for us it's the same thing: the c3 and c4 instances have nothing that can distinguish them, we can treat them identically.... > > 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..... It's no different than the way it works today. If you clone a browser you get the same request variable (containing the continuation id), if you clone a browser you get the same cookie. Data that travels with the browser continues to travel with the browser. Data that travels with the page continues to travel with the page? > > > 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? Yes, for three major instances: 1) an empty search screen, no data trivial case, but very common; 2) what we call a "grid" basically a table of existing data (eg. Surgeries for a given patient), with a row at the top of the table that allows adding new data. 90% of the time the user will just look at the existing list. On occasion they will add a new entry, but at that point the cache gets invalidated and a new page gets generated. 3) A page that is similar to a grid but every row can be simultaneously edited (eg. Lab values). The most general case can also be cached, but before we do that we'll have to beef up our event based cache invalidation. Right now it tracks only down to the service/page level (all users of a "service" share the same view of the data). To do general handling we'll also have to track the keys (in a database sense) used to retrieve the data. Pages can be cached by their service and keys. Each users continuation for a given page ties back to the particular cached instance. > > 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! Right. That's why I keep emphasizing that you want to separate business logic, presentation logic and flow logic. The idea of creating new variables within the flow and handing them to the page doesn't do this. IMO it might be nice for prototyping but it's not a good SOC. > <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 > > >
