cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Hunsberger, Peter" <Peter.Hunsber...@stjude.org>
Subject RE: Make continuation id available to all XSLTs
Date Fri, 26 Dec 2003 15:23:36 GMT
Marc Portier <mpo@outerthought.org> writes:

> 
> Hunsberger, Peter wrote:
> 
> > Sylvain Wallez <sylvain@apache.org> writes:
> > 
> > 
> >>Hunsberger, Peter wrote:
> >>
> >>
> 
> <snip />
> 
> > 
> >>On the other hand, I don't think that stylesheets generally need the
> >>continuation id, and that always including it would make many 
> >>pipelines 
> >>non-cacheable when they actually are.
> >>
> >>As a conclusion, I think it's better to pass the 
> continuation id as a
> >><map:parameter> where needed...
> > 
> > 
> > All right, I'll bite, how would you go about doing that?  
> That was my 
> > first thought but I couldn't find a way to do that...
> > 
> 
> hm. I thought there was an inputmodule for this.
> 
> I just checked the cocoon.xconf and found there a declared 
> JXPathMetaModule under the name "jxpath"
> 
> which lead me to believe something along the lines of 
> <map:parameter name="cont-id" 
> value="{jxpath:$continuation/id}" /> would do it
> 
> but that doesn't seem to work :-(
> 
> 
> delving in the code none of the modules seem to make the classic flow 
> parameters available (e.g. for comparison jxtemplate knows about 
> $continuation, $request, $session IIRC)
> 
> but maybe my understanding of modules is wrong to even expect this?

That was my finding also, I grepped the code base for everything that
looked like it could possibly work and found nothing, which is what lead
me to my proposal...

> 
> in any case, faster workaround might be to have the continuation-id 
> inserted earlier in the xml datastream (using jxtemplate, 
> woody or whatever)

In general, I can't see how moving this earlier would help?  If you
invalidate the cachability of any data steam everything that follows has
to be regenerated?  Certainly, in our case that heads the opposite
direction from what we want;  the closer to the back end you get the
more generic the data is and the more cacheable it is.  The closer you
get to the front end you get the more customized the data stream is to
the individual user and as a result caching has less benefit.  

However, this seems to be a big problem with flow?  You need a
continuation id but it is unique to every page request, therefore, the
final data stream cannot be cacheable across multiple users or even for
a single user across multiple iterations of the same process (eg. add
patient 1, add patient 2, add patient 3....)?  

If Cocoon had a way to add a cookie to the header on the way out and
extract the continuation id from the header on the way back everything
would be fine (except for external caching) but then you've just
reinvented session management as implemented by many servlet engines?
What am I missing here?



Mime
View raw message