> 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:
<map:aggregate element="list" src="data/list.xml"/>
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:
<map:generate ...>
<map:cache-currency-list>file1, file2, ...</cache-currency-list>
<map:cache-currency-generator type="generator-name"/>
</map:generate>
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. <http://xml.apache.org/cocoon/faqs.html>
To unsubscribe, e-mail: <[EMAIL PROTECTED]>
For additional commands, e-mail: <[EMAIL PROTECTED]>
