Key must identify your generated page, and it does not necessary mean that
one XSP file must have just one key - because one XSP file may generate lots of pages
depending
on environment parameters. Consider following example: XSP generates a catalogue page
and takes a
parameter CategoryID.
Then, good example of key method would be:
public long generateKey(){
// Unique ID of your page
String CategoryID = request.getParameter(ID); // Get CategoryID parameter used
to generate XSP
return HashUtil.hash(getClass().getName() + CategoryID);
}
> About caching... another question: the caching validity is
> application-relative, session-relative or page-relative?
Then, answering on your question, validity must be generated in scope of this key - in
our example, in
scope of catalogue category:
public CacheValidity generateValidity(){
String CategoryID = request.getParameter(ID); // Get CategoryID parameter used
to generate XSP
return new TimeStampValidity(
MyCatalogue.getCategory(CategoryID).modificationTime() );
}
Then XSP page representing CategoryID=XXX would be regenrated ONLY when this category
has been changed.
> Is there any way to define application-scope variables within cocoon?
Can't suggest you anything right now...
Vadim
> -----Original Message-----
> From: Paolo [mailto:[EMAIL PROTECTED]]
> Sent: Tuesday, September 25, 2001 9:17 AM
> To: [EMAIL PROTECTED]
> Subject: R: Pipeline caching...
>
>
> Hi Vadim...
> Thank you for your precious reply!
>
> About caching... another question: the caching validity is
> application-relative, session-relative or page-relative?
>
> Is there any way to define application-scope variables within cocoon?
>
> Thank you,
> Paolo Scaffardi
> AIRVENT SAM S.p.A.
>
> -----Messaggio originale-----
> Da: Vadim Gritsenko [mailto:[EMAIL PROTECTED]]
> Inviato: luned́ 24 settembre 2001 17.06
> A: [EMAIL PROTECTED]
> Oggetto: RE: Pipeline caching...
>
> By default XSP generated by Cocoon are not cached, and executed on every
> request.
> To change this behaviour, you need to add these two methods:
>
> <xsp:page language="java" xmlns:xsp="http://apache.org/xsp";>
> <xsp:logic>
> public long generateKey(){
> // Unique ID of your page
> return HashUtil.hash(getClass().getName());
> }
> public CacheValidity generateValidity(){
> // Modify according to your needs
> return new NOPCacheValidity();
> }
> </xsp:logic>
>
> If you add snippet shown above, your XSP would be executed ONLY ONCE and
> cached FOREVER by Cocoon.
> Another example of validity method is:
>
> public CacheValidity generateValidity(){
> if(changed) return null;
> return new NOPCacheValidity();
> }
>
> This would invalidate cache entry every time you decide (using if()
> statement) to re-generate XSP.
>
> Vadim
>
> > -----Original Message-----
> > From: Paolo [mailto:[EMAIL PROTECTED]]
> > Sent: Monday, September 24, 2001 10:42 AM
> > To: Cocoon-Users; [EMAIL PROTECTED]
> > Subject: Pipeline caching...
> >
> >
> > I am working on a web application bases on Cocoon 2. Every page of my
> > application has to be created by applying a stylesheet to many
> > aggregated pipelines. Some of these are generated by XSP and querying
> > databases.
> >
> > Some of these XML components don't change into a session, then I can
> > generate them the first time only, store somewhere and reload them
> fast
> > without reprocess every pipeline during the session.
> >
> > I trying using the WriteDOM/ReadDOM transformers but I really don't
> know
> > how to use that because of their transformer-nature (how can use a
> > stored DOM tree as generator?).
> >
> > What I am asking is simple: is there any way to cache a pipeline in
> this
> > way, simply by adding a parameter to the pipeline definition instead
> of
> > many selectors/transformers to do that?
> >
> > Is there anyone that is working on a feature like that?
> >
> > This is my sitemap:
> >
> > <!-- HOME PAGE -->
> > <map:match pattern="home_*">
> > <map:aggregate element="gportal">
> > <map:part src="cocoon:/dbhotel"/> <!-- fixed in session
> > -->
> > <map:part src="cocoon:/dbroom"/> <!-- fixed in session
> > -->
> > <map:part src="cocoon:/dbcustomer"/> <!-- fixed in
> > session -->
> > <map:part src="cocoon:/dbdays"/> <!-- fixed in session
> > -->
> > <map:part src="cocoon:/otherpipelines"/> <!-- changes in session
> > -->
> > </map:aggregate>
> > <map:transform src="documents/{1}/home.xsl"/>
> > <map:serialize/>
> > </map:match>
> >
> > Where dbhotel, dbroom and dbcustomer are something like:
> >
> > <map:match pattern="dbroom">
> > <map:generate src="documents/shared/xsp/dbroom.xsp"
> > type="serverpages"/>
> > <map:serialize type="xml"/>
> > </map:match>
> >
> > What do you think about that?
> >
> > Thanx,
> > Paolo Scaffardi
> > AIRVENT SAM S.p.A.
> >
> >
> >
> > ---------------------------------------------------------------------
> > Please check that your question has not already been answered in the
> > FAQ before posting. <http://xml.apache.org/cocoon/faqs.html>
> >
> > To unsubscribe, e-mail: <[EMAIL PROTECTED]>
> > For additional commands, e-mail: <[EMAIL PROTECTED]>
> >
> >
>
> ---------------------------------------------------------------------
> Please check that your question has not already been answered in the
> FAQ before posting. <http://xml.apache.org/cocoon/faqs.html>
>
> To unsubscribe, e-mail: <[EMAIL PROTECTED]>
> For additional commands, e-mail: <[EMAIL PROTECTED]>
>
>
>
> ---------------------------------------------------------------------
> Please check that your question has not already been answered in the
> FAQ before posting. <http://xml.apache.org/cocoon/faqs.html>
>
> To unsubscribe, e-mail: <[EMAIL PROTECTED]>
> For additional commands, e-mail: <[EMAIL PROTECTED]>
>
>
---------------------------------------------------------------------
Please check that your question has not already been answered in the
FAQ before posting. <http://xml.apache.org/cocoon/faqs.html>
To unsubscribe, e-mail: <[EMAIL PROTECTED]>
For additional commands, e-mail: <[EMAIL PROTECTED]>
