cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Leszek Gawron <>
Subject Re: Caching jx *without* flow
Date Tue, 19 Sep 2006 14:16:04 GMT
Thorsten Scherler wrote:
> On Mon, 2006-09-18 at 11:39 +0200, Leszek Gawron wrote: 
> ....
>>> Hmm, maybe the documentation is outdated but
>>> 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 
> Will have a closer look to get the big picture but the class name sounds
> heavily like we assume a flow environment.
It was TemplateObjectModelHelper but Carsten refactored some 
functionality outside and thus the class name. We should probably change it.

>> Could you give me a full example of what you want to achieve?
> 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?
Yes you're right. I'll have a look into the code you provided and have 
comments later.

>>>> 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.
The comfortable fallback is not to use caching at all. At least not in 
the default JXTG configuration. Any jx based web application does not 
perform any caching.

We could probably introduce some JTXG configuration parameters like xslt 

    <!-- NOTE: This is the default XSLT processor. -->
    <map:transformer logger="sitemap.transformer.xslt" name="xslt" 
pool-max="32" src="org.apache.cocoon.transformation.TraxTransformer">

If user wants to make JXTG automatically cacheable he/she must 
explicitly state it in configuration:

<map:generator src="org.apache.cocoon.template.JXTemplateGenerator">

Still it would be way cool if we could limit template's object model to 
portions we want to use. Otherwise this is very error prone.

I will try to implement the feature this week (if noone objects).

Leszek Gawron, IT Manager                          MobileBox sp. z o.o.
+48 (61) 855 06 67                    
mobile: +48 (501) 720 812                       fax: +48 (61) 853 29 65

View raw message