RE: Detecting change on XML included with document() to reset cache?

[Hunsberger, Peter]

> With care you may be able to do this in a portable way though not with the
> document function.  The problem I see with asking the file generator to
> check dependencies is the overhead of parsing the entire document on every
> request.

That's a reasonable idea; one could code the xsl to pick up a parameter from
cocoon to alternate behavior between using document() and cinclude.  Not
completely clean, but not too horrible.

It turns out that using an aggregate in a pipeline requires only two trivial
changes to the style sheet, so I can code the stylesheet in a portable
manner (ie; again an xsl:choose on a passed parameter when using Cocoon).
However, I still have the security/integrity of the sitemap issue. I could
get around this by building a application to maintain the sitemap but that's
obviously a tad bit of work. Alternately, if one could specify an external
file for an map:aggregate that would solve the security/integrity issue; eg:



If I can't get that, what I'd like is a way to tell a caching generator to
check some other file list (or generator for that matter) for currency, eg:

   
file1, file2, ...

   

In the first case a simple hash map of timestamps on the files would work,
in the 2nd case some timestamp passed back from some standard method in the
generator interface would do the trick, it wouldn't even have to be a
timestamp: if the returned string changes from call to call invalidate the
cache.  It seems to me that this might also help simplify implementation of
some of the other cache control mechanisms that have been floating around
the list in the last couple of weeks. (And, no, I'm sorry, I don't currently
have time to write the code.)  


-
Please check that your question has not already been answered in the
FAQ before posting. 

To unsubscribe, e-mail: <[EMAIL PROTECTED]>
For additional commands, e-mail: <[EMAIL PROTECTED]>

RE: Detecting change on XML included with document() to reset cache?

[Geoff Howard]

could you just transform the list xml to cinclude the others via cocoon
pseudo-urls?

...

  http://apache.org/cocoon/include/1.0";>

  



  
  
cocoon:/
  


Something like that?  I didn't test the attribute setting there - you may
need to do something trickier like set a variable and then use concat().

With care you may be able to do this in a portable way though not with the
document function.  The problem I see with asking the file generator to
check dependencies is the overhead of parsing the entire document on every
request.

Geoff Howard

-Original Message-
From: Hunsberger, Peter [mailto:[EMAIL PROTECTED]]
Sent: Tuesday, May 21, 2002 11:38 AM
To: '[EMAIL PROTECTED]'
Subject: Detecting change on XML included with document() to reset
cache?


Using Cocoon 2.0.2 Tomcat 4.0.4b JBoss 2.4.4 JRE 1.4.0

I have a straight forward sub-site that invokes a simple 1 stage XML to HTML
pipeline.  The main xml target of the pipeline is just a list of the real
xml files that are to be processed, eg:


   file-a.xml
   file-b.xml
   file-c.xml
 

The style sheet uses the XSLT document() function to process these files.
The problem is that usually only the referenced files are updated, the main
xml and xsl are mostly static.  As a result Cocoon never sees the changes
and never clears the cache.  Is there a simple way to tell Cocoon to check
the referenced files?  

I realize I could restructure this to have a Cocoon pipeline aggregate the
files and process them.  However, that approach has two problems: 1) the
current method is portable to any XSLT engine; 2) the XML file that
determines the included files is visible to the users for when an occasional
update is required.  I don't want to expose the sitemap to the users due to
security/integrity and training issues.

Peter Hunsberger

Phone: 901-495-5252
E-mail: [EMAIL PROTECTED]


-
Please check that your question has not already been answered in the
FAQ before posting. 

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. 

To unsubscribe, e-mail: <[EMAIL PROTECTED]>
For additional commands, e-mail: <[EMAIL PROTECTED]>