Return-Path: Delivered-To: apmail-cocoon-users-archive@www.apache.org Received: (qmail 24000 invoked from network); 6 Jul 2004 09:25:51 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (209.237.227.199) by minotaur-2.apache.org with SMTP; 6 Jul 2004 09:25:51 -0000 Received: (qmail 56988 invoked by uid 500); 6 Jul 2004 09:25:29 -0000 Delivered-To: apmail-cocoon-users-archive@cocoon.apache.org Received: (qmail 56836 invoked by uid 500); 6 Jul 2004 09:25:27 -0000 Mailing-List: contact users-help@cocoon.apache.org; run by ezmlm Precedence: bulk list-help: list-unsubscribe: list-post: Reply-To: users@cocoon.apache.org Delivered-To: mailing list users@cocoon.apache.org Received: (qmail 56757 invoked by uid 99); 6 Jul 2004 09:25:26 -0000 X-ASF-Spam-Status: No, hits=0.0 required=10.0 tests= X-Spam-Check-By: apache.org Received: from [212.85.125.162] (HELO v07274.home.net.pl) (212.85.125.162) by apache.org (qpsmtpd/0.27.1) with SMTP; Tue, 06 Jul 2004 02:25:25 -0700 Received: from sj162.internetdsl.tpnet.pl (HELO ?192.168.1.22?) (lgawron.mobilebox@home@80.55.87.162) by matrix15.home.net.pl with SMTP; 6 Jul 2004 09:24:50 -0000 Message-ID: <40EA6FDF.2070607@mobilebox.pl> Date: Tue, 06 Jul 2004 11:24:47 +0200 From: Leszek Gawron User-Agent: Mozilla Thunderbird 0.6 (Windows/20040502) X-Accept-Language: en-us, en MIME-Version: 1.0 To: users@cocoon.apache.org Subject: Re: Caching JXTemplate References: <20040705153111.GA31750@maribor.izzy.net> <40E9B32C.9030300@upaya.co.uk> <33886.10.0.0.5.1089077230.squirrel@10.0.0.5> <40EA3C04.4070902@upaya.co.uk> <34798.10.0.0.5.1089093450.squirrel@10.0.0.5> <40EA49EB.9060803@hippo.nl> <40EA4F00.6020405@hippo.nl> In-Reply-To: <40EA4F00.6020405@hippo.nl> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Checked: Checked X-Spam-Rating: minotaur-2.apache.org 1.6.2 0/1000/N Unico Hommes wrote: > Unico Hommes wrote: > >> Antonio Gallardo wrote: >> >>> Upayavira dijo: >>> >>> >>>> Antonio Gallardo wrote: >>>> >>>> >>>> >>>>> Upayavira dijo: >>>>> >>>>> >>>>> >>>>> >>>>>> Alan wrote: >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>>> I'm wondering if there is a way to cache JXTemplate, or any >>>>>>> ordinarily uncachable pipeline, maybe from flowscript, by teling >>>>>>> Cocoon that for this URL this pipeline will not change. >>>>>>> >>>>>>> I have a JXTemplate that generates some XML based on request >>>>>>> parameters, and for a given query string, it will always produce >>>>>>> the same XML output. >>>>>>> >>>>>>> Thank You. >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>> >>>>>> >>>>>> JXTemplateGenerator in CVS is cachable now. >>>>>> >>>>>> See: >>>>>> http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=108607750303449&w=2 >>>>>> for >>>>>> the original 'spec' that is what I believe has been implemented. >>>>>> >>>>>> >>>>>> >>>>> >>>>> >>>>> Hi: >>>>> >>>>> In the CVS the JXTG includes a patch that cache the compiled JXTG >>>>> source. >>>>> That way a second run is only interpreted. Before the patch JXTG >>>>> compiled >>>>> and then interpreted the JXT source file. >>>>> >>>>> Is this what you are expecting? >>>>> >>>>> >>>>> >>>>> >>>> >>>> >>>> This is not what I was suggesting. The patch that I understand has been >>>> made allows the caching system to decide whether or not to cache the >>>> page. Hence, generation is avoided completely if necessary (of course >>>> the page needs to be interpreted to identify the caching details, but >>>> much less work is required than if full generation takes place. >>>> >>> >>> >>> >>> I am not sure if this was coded after the discussion. Can you provided >>> info about the status of that? >>> >>> >>> >> >> Surely you couldn't have missed it. You committed it: >> >> http://cvs.apache.org/viewcvs.cgi/cocoon-2.1/src/java/org/apache/cocoon/generation/JXTemplateGenerator.java?r1=1.46&r2=1.47 >> >> >> Now reviewing the patch, I can't imagine how this is going to work. >> Both cache key and validity objects that are passed in via the context >> seem to be returned without augmenting them. AFAICS they should be >> combined with a key identifying the src of the generator and the >> validity of that src respectively in order to work. >> >> > > Oh but I think I see now. The cache-key and cache-validity objects are > associated with the compiled template object using template properties. > The compiled template in turn is cached directly by the generator using > the validity of the src of the generator. That should work. > > So now how to use this feature. If I read this correctly cache-key and > cache-validity attributes can be specified on an element anywhere in the > xml: > > jx:cache-validity="${cacheValidityExpression}" /> Yes it is. I am thinking about a slight change. Right now every xml node is parsed for jx:* attributes. What I would like to do is to introduce wdyt? -- Leszek Gawron lgawron@mobilebox.pl Project Manager MobileBox sp. z o.o. +48 (61) 855 06 67 http://www.mobilebox.pl mobile: +48 (501) 720 812 fax: +48 (61) 853 29 65 --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org For additional commands, e-mail: users-help@cocoon.apache.org