Vadim Gritsenko <[EMAIL PROTECTED]> points out: > > Torsten Curdt wrote: > > > Hunsberger, Peter wrote: > > > >> To follow up with an old post about handling continuation ids as > >> request parameters and how that could cause caching problems: > >> > >> I wrote a quick set of changes to add the continuation id > as a cookie > >> in the setup method of one of my generators as follows: > > > > > > ...wait a minute! > > > > Continuations cannot work with cookies or sessions. > > The continuations id is per individual page! > > > > Or did I miss here something? > > > No, you've not. Usually, continuation is valid only for a particular > page, and you can return to some other continuation. But I > can imagine > situation when flow is connected to some stateful app, where > you can't > go back to previous continuation. In such rare cases, it will > make sense > to have continuation in a cookie. But this is not helpful for > generic app.
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); 2) use different cookie paths for each flow that needs a separate state. 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. Of course the other issue is what to do with users who don't have cookies enabled, that's not an issue for use since we're building an Intranet app and require cookies. However, for the general use case, this does take one full circle: what do you do about the fact that you can't cache pages that have continuation id's embedded in them?
