Torsten Curdt <[EMAIL PROTECTED]> writes: > > > Ahh, I see what the issue is in general: there are > currently no places > > in our app where we've got anything other than a two state > flow: GET > > -> POST jumping to another flow is a completely different GET/POST > > pair, thus a new cookie and a new continuation. Two ways > around this: > > > > 1) concatenate the continuation id's in the cookie, something like > > |c1|c2|c3|...|cn| then parse them as needed (treat it like a LIFO > > stack); > > Hm... I cannot see how this would help. Continuations have > there "stack" on the server side.
In general you're right it's not useful, you'd only be able to support this with a back button on the page that told the server to pop the stack. You wouldn't have browser back button support. > > > 2) use different cookie paths for each flow that needs a separate > > state. > > Keep in mind that the flow is not linear but can be tree > based!! And there is no direct relation of path and > continuation - even per client. You will understand as soon > as you continue your flow in a new browser window. > > > This is pretty much transparent if set up properly and I > think for us > > it would be simply a matter of using the page name as an additional > > path > > specifier: server/page/page and then ignoring the > redundant information > > in the sitemap. > > Can you elaborate a bit? I don't understand how this could help. > The issue is, in general, you want to associate a continuation with a particular user and a particular page. As you point out, using a single cookie doesn't work for the general case since you loose the per page association. However, a somewhat more general solution is to exploit cookie paths to allow one cookie per page. To do this you have to have a unique path to each page. The cookie rules are that you can look down the path but you can't place a cookie at a place higher up the path than the page. IOW, sever/x/x.html can have a cookie at path "x" or at "/" but not at "x/y". So, you basically hack Cocoon to add a redundant piece of path information to each page request that you then factor back out in the site map. This works, I tested it yesterday, but I've since thought of a better solution which I'll post later today once I get a chance to test it. (The general problem is that not all sites can allow the page paths to be hacked in the manner I describe...) > <snip/> > > > what do you do about the fact that you > > can't cache pages that have continuation id's embedded in them? > > Well, as you say: it's a fact ;) > ...nothing much you can do about it > I think there is :-) look for a post with a title something like "Continuations break caching - possible solution" later today... The solution still requires session management, but it's more general and easier to implement than what I've been playing with so far.
