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 [EMAIL PROTECTED] [EMAIL PROTECTED]
