Thorsten Scherler wrote:
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.
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?
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?
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
does:
<!-- NOTE: This is the default XSLT processor. -->
<map:transformer logger="sitemap.transformer.xslt" name="xslt"
pool-max="32" src="org.apache.cocoon.transformation.TraxTransformer">
<use-request-parameters>false</use-request-parameters>
<use-session-parameters>false</use-session-parameters>
<use-cookie-parameters>false</use-cookie-parameters>
<xslt-processor-role>xalan</xslt-processor-role>
<check-includes>true</check-includes>
</map:transformer>
If user wants to make JXTG automatically cacheable he/she must
explicitly state it in configuration:
<map:generator src="org.apache.cocoon.template.JXTemplateGenerator">
<automatic-cache-key>
<use-sitemap-parameters>true</use-sitemap-parameters>
<use-request-parameters>true</use-request-parameters>
<use-request-attributes>true</use-request-attributes>
<use-session-parameters>false</use-session-parameters>
<use-cookie-parameters>false</use-cookie-parameters>
</automatic-cache-key>
</map:generator>
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 http://www.mobilebox.pl
mobile: +48 (501) 720 812 fax: +48 (61) 853 29 65
