Time to scratch the "how best to optimize Cocoon caching with respect to continuations" itch once more...
I've posted previously about how we ended up creating a continuations manager that manages a hash map of continuations in session for each user. This works fine, except for two things: 1) you can't manage browser forking (a user opening a second browser instance on a form). This is generally ok with us, it's not a use case we have any reason to support, but if we could support it, it would be nice; 2) we have to write flow logic to invalidate our managed continuations for those cases where we don't want to allow reuse of the continuation. Sort of the inverse of the normal Cocoon continuations management where you have to write code to explicitly reuse a continuation. With complex flows the second issue keeps exposing bugs, we find strange use cases where we've got to sometimes allow a continuation to be reused and sometimes not allow it. If we went back to the default Cocoon handling of continuations these corner cases would go away (since each page would have it's own continuation) BUT we'd loose caching for those pages where we can currently reuse the continuation. It seems it would be simple to write a ContinuationsTransformer or ContinuationsSerializer that augmented any <form> tag with an action pointing to the appropriate continuation (essentially a simpler version of the URI rewriting transformer). However, if you just do this blindly each resultant instance of the page is unique and you loose caching. Soooo, is it possible to inspect the cache validity chain of a pipeline from within a Transformer or Serializer? If it is, the strategy I would use is to have every Generator and Transformer we use implement Cacheable and if we have user unique data for a given Transformer or Generator it would create a null CacheValidity. The ContinuationsTransformer/Serializer would then know it can't just reuse any existing instance of the continuation for that page (if one already exists) but instead does the normal thing. With a strategy like this we'd still have the first problem some of the time (forks wouldn't be unique for some pages), but the rest of the Continuation handling now goes back to looking like normal Cocoon continuations handling. Does this make any sense? Is it even conceptually possible for a Transformer or Serializer to inspect the CacheValidity objects? If both can do it which is better? Serializer seems more likely, but then I'm mixing concerns. OTOH, I'd only need this for XHTML so I can just sort of ignore that. It occurs to me that if the answer to this question is yes for Serializers, then you might also want a similar strategy to determine how to set HTTP headers: any null validity means the page expires immediately? If so, then with that approach I've also solved some of the browser back button issues simultaneously. Peter Hunsberger
