You're right that file generator should automatically cache based on last modified stamp of the file(s) involved. You could monitor the logs to see if it's serving cached content for that or not. If not, first check for steps in the pipeline which may not cache - if it's just filegenerator->xslt->html that should be caching and if its not it may be a bug.
Geoff -----Original Message----- From: Derek Hohls [mailto:[EMAIL PROTECTED]] Sent: Wednesday, January 29, 2003 1:22 AM To: [EMAIL PROTECTED] Subject: Re: proposal: "The Newbies Competence Center" (XSLT) Miles Thanks for the extra insight. Actually, the XSP and XSLT issues are separate for me - the XSP is generating relatively small sets of data, and the XSLT is also not that complex. However, I have relatively large static XML files that I am trying to process using the full DocBook XSLT code. These seem to go *very* slowly... could one cache these - my (very limited) understanding of caching suggests that file genereated XML is automaticaly cached, or not? Thanks Derek >>> [EMAIL PROTECTED] 28/01/2003 09:36:39 >>> Derek Hohls wrote: > (... the example below says one has to know how to do caching of XSPs' - > I still do not know how to do this but fortunately no one has yet > complained > about the speed of the generators - to me the issue is optimizing the > speed > of the transformers - anyone tried doing DocBook on the fly?? -- but the > point is here is that you dont' need to know this stuff in order to > get started; > optimization is a second or third order stage of learning) Here's the problem: While it's true that XSPs (and generators by association) are incredibly fast for the most part, the lack of caching can be a serious bottleneck because, as you point out, the generators are just the first part of a chain. XSLT transformers are usually cacheable. Put two or three transformers in a chain and you're looking at some processing time. If your underlying XSP isn't caching, the transformers can't cache and have to reprocess the same data over again. If the XSP caches, the transformations cache as well; It's a double win! Cocoon 2.0.4 has a caching XSP example already. In CVS, the caching API has changed and the example no longer works; However, there's a wiki doc on a 2.1dev version: http://wiki.cocoondev.org/Wiki.jsp?page=XSPCachingWithCocoonHEAD And I do DocBook-like transformations. Actually, we use a superset of Simplified DocBook (http://www.oasis-open.org/docbook/xml/simple/). Most of the transformations templates are very simple (eg. <para> to <p>, <ulink> to <a>). - Miles > I'm at about level 4c now... and at each stage I get new insights into > just how powerful and essential the sitemap is. I can almost see it now: resumes with the Cocoon levels. Java: 3 years; Intermediate C++: 5 years; Advanced COBOL: 12 years; Advanced Cocoon: 2 years; Level 7 ;-) - Miles --------------------------------------------------------------------- Please check that your question has not already been answered in the FAQ before posting. <http://xml.apache.org/cocoon/faq/index.html> To unsubscribe, e-mail: <[EMAIL PROTECTED]> For additional commands, e-mail: <[EMAIL PROTECTED]> -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. "The CSIR exercises no editorial control over E-mail messages and/or attachments thereto/links referred to therein originating in the organisation and the views in this message/attachments thereto are therefore not necessarily those of the CSIR and/or its employees. The sender of this e-mail is, moreover, in terms of the CSIR's Conditions of Service, subject to compliance with the CSIR's internal E-mail and Internet Policy." --------------------------------------------------------------------- Please check that your question has not already been answered in the FAQ before posting. <http://xml.apache.org/cocoon/faq/index.html> To unsubscribe, e-mail: <[EMAIL PROTECTED]> For additional commands, e-mail: <[EMAIL PROTECTED]>
