Mailing-List: contact dev-help@cocoon.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@cocoon.apache.org
Subject: Re: Caching jx *without* flow
From: Thorsten Scherler <thorsten.scherler@wyona.com>
To: dev@cocoon.apache.org
In-Reply-To: <450E6966.60108@mobilebox.pl>
References: <1158349311.17986.4.camel@localhost>
	 <450D361D.1070407@mobilebox.pl> <450E4BE7.40103@hippo.nl>
	 <450E5340.2030804@mobilebox.pl> <1158569825.4930.34.camel@localhost>
	 <450E6966.60108@mobilebox.pl>
Content-Type: text/plain
Date: Tue, 19 Sep 2006 13:51:17 +0200
Message-Id: <1158666677.6459.41.camel@localhost>
Mime-Version: 1.0
Content-Transfer-Encoding: 7bit

On Mon, 2006-09-18 at 11:39 +0200, Leszek Gawron wrote: 
....
> > Hmm, maybe the documentation is outdated but
> > http://cocoon.apache.org/2.1/userdocs/flow/jxtemplate.html state "When
> > used inside flow, JXTemplate has access to Java and can therefore
> > evaluate expressions like "java.util.Date()" or "java.util.HashMap()".
> > This does NOT work when JXTemplates are used without flow."
> 
> NOT true. Even if you are not using flow JXTG makes use of Rhino's 
> (javascript engine) NativeJavaPackage. Have a look at 
> https://svn.apache.org/repos/asf/cocoon/trunk/blocks/cocoon-template/cocoon-template-impl/src/main/java/org/apache/cocoon/template/environment/FlowObjectModelHelper.java
> 

Will have a closer look to get the big picture but the class name sounds
heavily like we assume a flow environment.

> 
> I see that http://cocoon.apache.org/2.1/userdocs/flow/jxtemplate.html is 
> heavily outdated.
> 
> > 
> > Wouldn't that mean that the example would not work without flow?
> > 
> > Further regarding the validity as I understand your example this would
> > not allow to use an AggregatedValidity which would be extended for all
> > <jx:import/>, or? 
> > 
> > Or could I do 
> > <jx:set var="validity" value="new AggregatedValidity()"/> 
> > ...
> > <jx:set var="validity" value="${validity.add(importValidity)}
> > ...
> I do not remember the details but the aggregated validity is way more 
> complicated than it seems after a short glance. Just as in xslt you have 
> to touch the main stylesheet if you change any imported ones - otherwise 
> cocoon does not see the changes.
> 
> Could you give me a full example of what you want to achieve?
> 

http://svn.apache.org/viewvc?view=rev&rev=447311

If we had a simple transformer then we can walk the SAX events and as
soon we find an import we add the imported source to the validity. This
work fine with an AggregatedValidity. Where the first validity is the
src file of the jx. 

The above example acts on a <forrest:contract/>. A contract is a single
unit of content. A contract consist ATM out of a xsl. This xsl can be
dispatched against a data uri and the result gets then added in place
(simplifying here). 

<jx:import/> do a similar task. Meaning one would want to extend the
method treating the import to add to the aggregated validity. This way
as soon as an import source get changed the cache get invalid. 

The biggest problem with the inline jx:cache-validity I see is that it
will only act on the main source and not on any imports, right?

> > 
> >> We could probably add this class to cocoon-template block and provide 
> >> some samples. Still - nothing needs to be changed.
> > 
> > Yeah that would be awesome. Still I am not sure whether the forrest
> > community would accept the inline solution. I understand your point
> > though, but under the user perspective I am with Niels.
> 
> What I dislike most about the idea is that the caching is done 
> automatically without user knowing. Moreover it is done for all jxtg 
> runs, not only the chosen ones.

Why not have the both solution hand in hand. 
Meaning if there is no jx:cache-key and jx:cache-validity using the sitemap input parameter
approach as fallback. This lets you still define inline but with a comfortable fallback.

wdyt?

salu2
-- 
Thorsten Scherler
COO Spain
Wyona Inc.  -  Open Source Content Management  -  Apache Lenya
http://www.wyona.com                   http://lenya.apache.org
thorsten.scherler@wyona.com                thorsten@apache.org