You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cocoon.apache.org by Thorsten Scherler <th...@apache.org> on 2006/09/15 21:41:51 UTC
Caching jx *without* flow
Hi all, hi Ard,
http://marc.theaimsgroup.com/?l=xml-cocoon-users&m=115194685214066&w=2
"...
> > Now, the cached jx would depend on these three parameters.
> Very easy to use, and less error prone than the flow part.
> >
> > If somebody is interested in the code I will hear "
Yes very interested.
http://svn.apache.org/viewvc?view=rev&rev=446701
https://issues.apache.org/jira/browse/FOR-931
Can you attach a patch to this issue or commit it to cocoon directly?
Would be awesome.
salu2
--
thorsten
"Together we stand, divided we fall!"
Hey you (Pink Floyd)
Re: Caching jx *without* flow
Posted by Leszek Gawron <lg...@mobilebox.pl>.
Thorsten Scherler wrote:
>> <map:match pattern="foo">
>> <map:generate src="foobar.jx">
>
> that is the normal file generator which is indeed cacheable. I am
> talking about <map:generate type="jx" src="foobar.jx"> which is not
> cacheable (if not changed since the last update of the cocoon in
> forrest).
I am sorry - it should of course state <map:generate type="jx"
src="foobar.jx">
JXTG IS cacheable if you provide jx:cache-key and jx:cache-validity in
template body.
>> <map:parameter name="foo" value="bar"/>
>> <map:parameter name="bar" value="foo"/>
>> </map:generate>
>> <map:serialize/>
>> </map:match>
>>
>> so cocoon:/foo gets cached with something like "foo=bar&bar=foo"?
>>
>> Why need a patch for that? After all you already have jx:cache-key and
>> jx:cache-validity.
>
> Can you explain, I read the mail from Ard (see above marc link) and
> understood that one need to patch the jx generator to make it cacheable.
> If not can you give an example?
Please read my other reply. If I have time I will commit some samples to
trunk that would outline jxtg caching.
--
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
Re: Caching jx *without* flow
Posted by Thorsten Scherler <th...@apache.org>.
On Sun, 2006-09-17 at 13:48 +0200, Leszek Gawron wrote:
> Thorsten Scherler wrote:
> > Hi all, hi Ard,
> >
> > http://marc.theaimsgroup.com/?l=xml-cocoon-users&m=115194685214066&w=2
> > "...
> >>> Now, the cached jx would depend on these three parameters.
> >> Very easy to use, and less error prone than the flow part.
> >>> If somebody is interested in the code I will hear "
> >
> > Yes very interested.
> >
> > http://svn.apache.org/viewvc?view=rev&rev=446701
> > https://issues.apache.org/jira/browse/FOR-931
> >
> > Can you attach a patch to this issue or commit it to cocoon directly?
> >
> > Would be awesome.
> Do I get it right:
>
> you want to patch JXTG to automatically build up a cache key from cocoon
> parameters?
>
> <map:match pattern="foo">
> <map:generate src="foobar.jx">
that is the normal file generator which is indeed cacheable. I am
talking about <map:generate type="jx" src="foobar.jx"> which is not
cacheable (if not changed since the last update of the cocoon in
forrest).
> <map:parameter name="foo" value="bar"/>
> <map:parameter name="bar" value="foo"/>
> </map:generate>
> <map:serialize/>
> </map:match>
>
> so cocoon:/foo gets cached with something like "foo=bar&bar=foo"?
>
> Why need a patch for that? After all you already have jx:cache-key and
> jx:cache-validity.
Can you explain, I read the mail from Ard (see above marc link) and
understood that one need to patch the jx generator to make it cacheable.
If not can you give an example?
TIA
salu2
>
--
thorsten
"Together we stand, divided we fall!"
Hey you (Pink Floyd)
Re: Caching jx *without* flow
Posted by Thorsten Scherler <th...@apache.org>.
On Mon, 2006-09-18 at 09:33 +0200, Niels van Kampenhout wrote:
> Leszek Gawron wrote:
> > Thorsten Scherler wrote:
> >> Hi all, hi Ard,
> >>
> >> http://marc.theaimsgroup.com/?l=xml-cocoon-users&m=115194685214066&w=2
> >> "...
> >>>> Now, the cached jx would depend on these three parameters.
> >>> Very easy to use, and less error prone than the flow part.
> >>>> If somebody is interested in the code I will hear "
> >>
> >> Yes very interested.
> >> http://svn.apache.org/viewvc?view=rev&rev=446701
> >> https://issues.apache.org/jira/browse/FOR-931
> >>
> >> Can you attach a patch to this issue or commit it to cocoon directly?
> >>
> >> Would be awesome.
> > Do I get it right:
> >
> > you want to patch JXTG to automatically build up a cache key from cocoon
> > parameters?
> >
> > <map:match pattern="foo">
> > <map:generate src="foobar.jx">
> > <map:parameter name="foo" value="bar"/>
> > <map:parameter name="bar" value="foo"/>
> > </map:generate>
> > <map:serialize/>
> > </map:match>
> >
> > so cocoon:/foo gets cached with something like "foo=bar&bar=foo"?
> >
> > Why need a patch for that? After all you already have jx:cache-key and
> > jx:cache-validity.
> >
>
> Since Ard is on holiday until the GetTogether, I'll try to answer this
> question.
>
> The reason is, as Ard said, to make it less error prone. People easily
> make mistakes if they have to build a cachekey string themselves, en
> they also easily forget to actually put the jx:cache-key and
> jx:cache-validity attributes in the JX template. I am talking from
> experience!
Especially if one uses jx for pure presentation logic. The usecase in
forrest is that we use jx for the structurers (which are part of the
dispatcher). Meaning if we force the user to add above tags in the
jx:template, we will spend our days in answering the user mails that
forgot to add it or do not know how to do it, ...
>
> It also makes the code more readable/transparent/explicit, because you
> don't need the extra flow step anymore in many cases.
Like stated in the subject, we do not even use flow and adding flow only
for caching I consider kind of stupid.
Can you give a hint how to do it? Is it as simple as adding the params
to the cache key? If so would one use an aggregate validity since one
would need to add all <jx:import>'s to the validity object.
I just wrapped up the caching in the dispatcher and I reckon the jx
generator would need a similar patch like
http://svn.apache.org/viewvc?view=rev&revision=447311 (see
DispatcherTransformer.java)
http://svn.apache.org/viewvc/forrest/trunk/whiteboard/plugins/org.apache.forrest.plugin.internal.dispatcher/src/java/org/apache/forrest/dispatcher/transformation/DispatcherTransformer.java?r1=446701&r2=447311&pathrev=447311&diff_format=h
TIA
salu2
>
> Regards,
> Niels
>
--
thorsten
"Together we stand, divided we fall!"
Hey you (Pink Floyd)
Re: Caching jx *without* flow
Posted by Niels van Kampenhout <n....@hippo.nl>.
Leszek Gawron wrote:
> Niels van Kampenhout wrote:
>> Leszek Gawron wrote:
>>> The only thing that's missing from HippoJXTemplateGenerator.java
>>> functionality is the ability to exclude some parameters from cache
>>> key. Anyway this looks like FS from the start:
>>
>> What do you mean by FS? False Security?
> Flexibility Syndrome :)
Ah, ok! The lists of internet abbreviations I found through Google
actually all said it meant "For Sale" :-)
>>
>>> - if template makes use of all cocoon parameters they should be a part
>>> of the cache key,
>>> - if not - you shouldn't pass them instead of excluding.
>>>
>>> Please comment.
>>
>> These two statements are true, and exactly satisfy our requirements.
>> You may have other requirements, though.
> I was refering to jx:includeKey and jx:excludeKey parameters in your
> generator. Why do you use it at all?
I see what you mean now. I don't think we ever use those parameters, and
thinking about it, they do not make sense to me either. If you exclude a
sitemap parameter from the cache key, either you get a false cache
response or the sitemap parameter was not used in the template anyway.
>> What matters to me is this: in our projects we mainly use JXTG and
>> XSLT, and (as far as I can see from a user perspective) with our
>> solution the formation of the cache key is consistent between the two
>> (cocoon parameters == cache key). This is a big plus in the fragmented
>> world of Cocoon technologies.
> I like the analogy. In order to fully utilise it we would have to go
> further in similarities: JTGX object model in this case should be
> constructed only with sitemap parameters.
>
> automatic cache key from sitemap parameters + small object model = full
> XSLT analogy. We could try this.
And the cream on the cake would be to have the same expression language
in templates and XSLTs. I keep mixing those up....
>> Bottom line: we prefer different solutions and are both happy with
>> them. Good thing we live in a free world ;-)
> Agreed :)
Good, back to work then! :-)
Regards,
Niels
Re: Caching jx *without* flow
Posted by Leszek Gawron <lg...@mobilebox.pl>.
Niels van Kampenhout wrote:
> Leszek Gawron wrote:
>> Please update your cocoon checkout to the latest trunk. Then build
>> cocoon-webapp, run it and point your browser to:
>> http://localhost:8888/blocks/cocoon-template-sample/view/caching3
>>
>> The template header is:
>>
>> <page xmlns:jx="http://apache.org/cocoon/templates/jx/1.0"
>> jx:cache-key="${cocoon.request.parameters.toString()}"
>> jx:cache-validity="${Packages.org.apache.excalibur.source.impl.validity.NOPValidity()}">
>>
>>
>> you probably may do the same with
>> jx:cache-key="${cocoon.parameters.toString()}" which will
>> automatically build up cache-key out of all cocoon parameters passed
>> to the template. Haven't tested it though. This means you probably
>> don't even need any additional code to achieve your goals.
>
> I see what you mean, and I agree that it would allow us to do what we
> are doing now with our custom code.
>
> BTW, we use Cocoon 2.1.8, not the trunk.
This should also work with 2.1
>> The only thing that's missing from HippoJXTemplateGenerator.java
>> functionality is the ability to exclude some parameters from cache
>> key. Anyway this looks like FS from the start:
>
> What do you mean by FS? False Security?
Flexibility Syndrome :)
>
>> - if template makes use of all cocoon parameters they should be a part
>> of the cache key,
>> - if not - you shouldn't pass them instead of excluding.
>>
>> Please comment.
>
> These two statements are true, and exactly satisfy our requirements. You
> may have other requirements, though.
I was refering to jx:includeKey and jx:excludeKey parameters in your
generator. Why do you use it at all?
> What matters to me is this: in our projects we mainly use JXTG and XSLT,
> and (as far as I can see from a user perspective) with our solution the
> formation of the cache key is consistent between the two (cocoon
> parameters == cache key). This is a big plus in the fragmented world of
> Cocoon technologies.
I like the analogy. In order to fully utilise it we would have to go
further in similarities: JTGX object model in this case should be
constructed only with sitemap parameters.
automatic cache key from sitemap parameters + small object model = full
XSLT analogy. We could try this.
> Bottom line: we prefer different solutions and are both happy with them.
> Good thing we live in a free world ;-)
Agreed :)
--
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
Re: Caching jx *without* flow
Posted by Niels van Kampenhout <n....@hippo.nl>.
Leszek Gawron wrote:
> Please update your cocoon checkout to the latest trunk. Then build
> cocoon-webapp, run it and point your browser to:
> http://localhost:8888/blocks/cocoon-template-sample/view/caching3
>
> The template header is:
>
> <page xmlns:jx="http://apache.org/cocoon/templates/jx/1.0"
> jx:cache-key="${cocoon.request.parameters.toString()}"
> jx:cache-validity="${Packages.org.apache.excalibur.source.impl.validity.NOPValidity()}">
>
>
> you probably may do the same with
> jx:cache-key="${cocoon.parameters.toString()}" which will automatically
> build up cache-key out of all cocoon parameters passed to the template.
> Haven't tested it though. This means you probably don't even need any
> additional code to achieve your goals.
I see what you mean, and I agree that it would allow us to do what we
are doing now with our custom code.
BTW, we use Cocoon 2.1.8, not the trunk.
> The only thing that's missing from HippoJXTemplateGenerator.java
> functionality is the ability to exclude some parameters from cache key.
> Anyway this looks like FS from the start:
What do you mean by FS? False Security?
> - if template makes use of all cocoon parameters they should be a part
> of the cache key,
> - if not - you shouldn't pass them instead of excluding.
>
> Please comment.
These two statements are true, and exactly satisfy our requirements. You
may have other requirements, though.
What matters to me is this: in our projects we mainly use JXTG and XSLT,
and (as far as I can see from a user perspective) with our solution the
formation of the cache key is consistent between the two (cocoon
parameters == cache key). This is a big plus in the fragmented world of
Cocoon technologies.
Bottom line: we prefer different solutions and are both happy with them.
Good thing we live in a free world ;-)
Regards,
Niels
Re: Caching jx *without* flow
Posted by Leszek Gawron <lg...@mobilebox.pl>.
Niels van Kampenhout wrote:
>> We could probably add this class to cocoon-template block and provide
>> some samples. Still - nothing needs to be changed.
>>
>
> I must admit that I don't know much about JXTG from a developer's
> p.o.v., but from a user's p.o.v. (building web sites) our
> HippoJXTemplateGenerator [1] has been a huge improvement over the JXTG.
> But then, maybe JXTG has features that I don't know about which could
> make life easier without the modifications in [1]. I can't find them in
> the documentation [2,3] however. I guess I need to dive into the code
> for that ;-)
>
> Thanks,
> Niels
>
> [1]
> http://svn.hippocms.org/repos/hippo/hippo-cocoon-extensions/trunk/hippo-misc/src/java/nl/hippo/cocoon/generation/HippoJXTemplateGenerator.java
>
> [2] http://cocoon.apache.org/2.1/userdocs/jx-generator.html
> [3] http://wiki.apache.org/cocoon/JXTemplateGenerator
Please update your cocoon checkout to the latest trunk. Then build
cocoon-webapp, run it and point your browser to:
http://localhost:8888/blocks/cocoon-template-sample/view/caching3
The template header is:
<page xmlns:jx="http://apache.org/cocoon/templates/jx/1.0"
jx:cache-key="${cocoon.request.parameters.toString()}"
jx:cache-validity="${Packages.org.apache.excalibur.source.impl.validity.NOPValidity()}">
you probably may do the same with
jx:cache-key="${cocoon.parameters.toString()}" which will automatically
build up cache-key out of all cocoon parameters passed to the template.
Haven't tested it though. This means you probably don't even need any
additional code to achieve your goals.
The only thing that's missing from HippoJXTemplateGenerator.java
functionality is the ability to exclude some parameters from cache key.
Anyway this looks like FS from the start:
- if template makes use of all cocoon parameters they should be a part
of the cache key,
- if not - you shouldn't pass them instead of excluding.
Please comment.
--
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
Re: Caching jx *without* flow
Posted by Niels van Kampenhout <n....@hippo.nl>.
Leszek Gawron wrote:
> Niels van Kampenhout wrote:
>> Leszek Gawron wrote:
>>> Thorsten Scherler wrote:
>>>> Hi all, hi Ard,
>>>>
>>>> http://marc.theaimsgroup.com/?l=xml-cocoon-users&m=115194685214066&w=2
>>>> "...
>>>>>> Now, the cached jx would depend on these three parameters.
>>>>> Very easy to use, and less error prone than the flow part.
>>>>>> If somebody is interested in the code I will hear "
>>>>
>>>> Yes very interested.
>>>> http://svn.apache.org/viewvc?view=rev&rev=446701
>>>> https://issues.apache.org/jira/browse/FOR-931
>>>>
>>>> Can you attach a patch to this issue or commit it to cocoon directly?
>>>>
>>>> Would be awesome.
>>> Do I get it right:
>>>
>>> you want to patch JXTG to automatically build up a cache key from
>>> cocoon parameters?
>>>
>>> <map:match pattern="foo">
>>> <map:generate src="foobar.jx">
>>> <map:parameter name="foo" value="bar"/>
>>> <map:parameter name="bar" value="foo"/>
>>> </map:generate>
>>> <map:serialize/>
>>> </map:match>
>>>
>>> so cocoon:/foo gets cached with something like "foo=bar&bar=foo"?
>>>
>>> Why need a patch for that? After all you already have jx:cache-key
>>> and jx:cache-validity.
>>>
>>
>> Since Ard is on holiday until the GetTogether, I'll try to answer this
>> question.
>>
>> The reason is, as Ard said, to make it less error prone. People easily
>> make mistakes if they have to build a cachekey string themselves, en
>> they also easily forget to actually put the jx:cache-key and
>> jx:cache-validity attributes in the JX template. I am talking from
>> experience!
>>
>> It also makes the code more readable/transparent/explicit, because you
>> don't need the extra flow step anymore in many cases.
>
> 1. You don't need the extraflow step even right now. jx:cache-key and
> jx:cache-validity works no matter what controller was used.
>
> 2. The solution you are proposing is error prone. The jx object model
> does not get narrowed only to cocoon parameters so you are still able to
> use cocoon.session, cocoon.request.
>
> 3. I hardly see the point to make any JXTG customizations if you can do
> something like:
>
> <page
> jx:cache-key="${Packages.org.apache.cocoon.template.CocoonParametersCacheKeyBuilder.buildKey(
> cocoon.parameters )}" jx:cache-validity="${some validity}">
> <.../>
> </page>
>
> and
>
> public class CocoonParametersCacheKeyBuilder {
> public static String buildKey( Parameters parameters ) {
> // you probably need to sort cocoon parameters here so the order is
> // explicit
> StringBuffer buffer = new StringBuffer();
> String[] parameterNames = parameters.getNames();
> for ( int i = 0; i < parameterNames.length; ++i ) {
> String currentParameterName = parameterNames[ i ];
> if ( i > 0 )
> buffer.append( "&" );
> buffer.append( urlEncode( currentParameterName ) );
> buffer.append( "=" );
> buffer.append( urlEncode( parameters.getParameter(
> currentParameterName ) ) );
> }
> return buffer.toString();
> }
> }
>
> We could probably add this class to cocoon-template block and provide
> some samples. Still - nothing needs to be changed.
>
I must admit that I don't know much about JXTG from a developer's
p.o.v., but from a user's p.o.v. (building web sites) our
HippoJXTemplateGenerator [1] has been a huge improvement over the JXTG.
But then, maybe JXTG has features that I don't know about which could
make life easier without the modifications in [1]. I can't find them in
the documentation [2,3] however. I guess I need to dive into the code
for that ;-)
Thanks,
Niels
[1]
http://svn.hippocms.org/repos/hippo/hippo-cocoon-extensions/trunk/hippo-misc/src/java/nl/hippo/cocoon/generation/HippoJXTemplateGenerator.java
[2] http://cocoon.apache.org/2.1/userdocs/jx-generator.html
[3] http://wiki.apache.org/cocoon/JXTemplateGenerator
Re: Caching jx *without* flow
Posted by Antonio Gallardo <ag...@agssa.net>.
Leszek Gawron escribió:
> 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>
Hi Leszek,
Sorry to join the party too late. I have been busy the last months, but
I am still alive. :-)
I am just reading this mails and i will said: "Please forget the
following comment if you already discussed it":
It is fine to have a single place to define the jx caching behavior on
how it is going to generate the cache key. We also need to take into
account that in some cases the user may want a more fine grained
solution. Suppose the user wants (for some reason) to turn on jx caching
and avoid jx caching in few pipelines or the opposite: The user does not
want jx caching at all except in some few pipelines where he wants to
have jx cache working.
Given the above need we might use the standard parameter at the pipeline
level to overwrite default pipeline caching:
<map:generate src="myTemplate.jx" type="jx"/>
<map:parameter name="use-automatic-cache-key" value="true|false"/>
</map:generate>
Or somehow to overwrite the default configuration when we call the
generator.
Makes sense?
Best Regards,
Antonio Gallardo.
Re: Caching jx *without* flow
Posted by Leszek Gawron <lg...@mobilebox.pl>.
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
Re: Caching jx *without* flow
Posted by Thorsten Scherler <th...@wyona.com>.
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
Re: Caching jx *without* flow
Posted by Leszek Gawron <lg...@mobilebox.pl>.
Thorsten Scherler wrote:
> On Mon, 2006-09-18 at 10:05 +0200, Leszek Gawron wrote:
>> Niels van Kampenhout wrote:
>>> Leszek Gawron wrote:
>>>> Thorsten Scherler wrote:
>>>>> Hi all, hi Ard,
>>>>>
>>>>> http://marc.theaimsgroup.com/?l=xml-cocoon-users&m=115194685214066&w=2
>>>>> "...
>>>>>>> Now, the cached jx would depend on these three parameters.
>>>>>> Very easy to use, and less error prone than the flow part.
>>>>>>> If somebody is interested in the code I will hear "
>>>>> Yes very interested.
>>>>> http://svn.apache.org/viewvc?view=rev&rev=446701
>>>>> https://issues.apache.org/jira/browse/FOR-931
>>>>>
>>>>> Can you attach a patch to this issue or commit it to cocoon directly?
>>>>>
>>>>> Would be awesome.
>>>> Do I get it right:
>>>>
>>>> you want to patch JXTG to automatically build up a cache key from
>>>> cocoon parameters?
>>>>
>>>> <map:match pattern="foo">
>>>> <map:generate src="foobar.jx">
>>>> <map:parameter name="foo" value="bar"/>
>>>> <map:parameter name="bar" value="foo"/>
>>>> </map:generate>
>>>> <map:serialize/>
>>>> </map:match>
>>>>
>>>> so cocoon:/foo gets cached with something like "foo=bar&bar=foo"?
>>>>
>>>> Why need a patch for that? After all you already have jx:cache-key and
>>>> jx:cache-validity.
>>>>
>>> Since Ard is on holiday until the GetTogether, I'll try to answer this
>>> question.
>>>
>>> The reason is, as Ard said, to make it less error prone. People easily
>>> make mistakes if they have to build a cachekey string themselves, en
>>> they also easily forget to actually put the jx:cache-key and
>>> jx:cache-validity attributes in the JX template. I am talking from
>>> experience!
>>>
>>> It also makes the code more readable/transparent/explicit, because you
>>> don't need the extra flow step anymore in many cases.
>> 1. You don't need the extraflow step even right now. jx:cache-key and
>> jx:cache-validity works no matter what controller was used.
>>
>> 2. The solution you are proposing is error prone. The jx object model
>> does not get narrowed only to cocoon parameters so you are still able to
>> use cocoon.session, cocoon.request.
>
> Hmm, that is why Ard wrote:
> "> > now, to var ck you append the things that is depends on
>> (like a request parameter, current week number, etc)"
>
> Sure one need to take care to add all request parameter the jx depends on to the sitemap.
> I do not want to judge which method is more error prone, both have their pros and cons.
>
>> 3. I hardly see the point to make any JXTG customizations if you can do
>> something like:
>>
>> <page
>> jx:cache-key="${Packages.org.apache.cocoon.template.CocoonParametersCacheKeyBuilder.buildKey(
>> cocoon.parameters )}" jx:cache-validity="${some validity}">
>> <.../>
>> </page>
>>
>> and
>>
>> public class CocoonParametersCacheKeyBuilder {
>> public static String buildKey( Parameters parameters ) {
>> // you probably need to sort cocoon parameters here so the order is
>> // explicit
>> StringBuffer buffer = new StringBuffer();
>> String[] parameterNames = parameters.getNames();
>> for ( int i = 0; i < parameterNames.length; ++i ) {
>> String currentParameterName = parameterNames[ i ];
>> if ( i > 0 )
>> buffer.append( "&" );
>> buffer.append( urlEncode( currentParameterName ) );
>> buffer.append( "=" );
>> buffer.append( urlEncode( parameters.getParameter(
>> currentParameterName ) ) );
>> }
>> return buffer.toString();
>> }
>> }
>>
>
> 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
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?
>
>> 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.
Maybe other developers could comment.
--
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
Re: Caching jx *without* flow
Posted by Thorsten Scherler <th...@apache.org>.
On Mon, 2006-09-18 at 10:05 +0200, Leszek Gawron wrote:
> Niels van Kampenhout wrote:
> > Leszek Gawron wrote:
> >> Thorsten Scherler wrote:
> >>> Hi all, hi Ard,
> >>>
> >>> http://marc.theaimsgroup.com/?l=xml-cocoon-users&m=115194685214066&w=2
> >>> "...
> >>>>> Now, the cached jx would depend on these three parameters.
> >>>> Very easy to use, and less error prone than the flow part.
> >>>>> If somebody is interested in the code I will hear "
> >>>
> >>> Yes very interested.
> >>> http://svn.apache.org/viewvc?view=rev&rev=446701
> >>> https://issues.apache.org/jira/browse/FOR-931
> >>>
> >>> Can you attach a patch to this issue or commit it to cocoon directly?
> >>>
> >>> Would be awesome.
> >> Do I get it right:
> >>
> >> you want to patch JXTG to automatically build up a cache key from
> >> cocoon parameters?
> >>
> >> <map:match pattern="foo">
> >> <map:generate src="foobar.jx">
> >> <map:parameter name="foo" value="bar"/>
> >> <map:parameter name="bar" value="foo"/>
> >> </map:generate>
> >> <map:serialize/>
> >> </map:match>
> >>
> >> so cocoon:/foo gets cached with something like "foo=bar&bar=foo"?
> >>
> >> Why need a patch for that? After all you already have jx:cache-key and
> >> jx:cache-validity.
> >>
> >
> > Since Ard is on holiday until the GetTogether, I'll try to answer this
> > question.
> >
> > The reason is, as Ard said, to make it less error prone. People easily
> > make mistakes if they have to build a cachekey string themselves, en
> > they also easily forget to actually put the jx:cache-key and
> > jx:cache-validity attributes in the JX template. I am talking from
> > experience!
> >
> > It also makes the code more readable/transparent/explicit, because you
> > don't need the extra flow step anymore in many cases.
>
> 1. You don't need the extraflow step even right now. jx:cache-key and
> jx:cache-validity works no matter what controller was used.
>
> 2. The solution you are proposing is error prone. The jx object model
> does not get narrowed only to cocoon parameters so you are still able to
> use cocoon.session, cocoon.request.
Hmm, that is why Ard wrote:
"> > now, to var ck you append the things that is depends on
> (like a request parameter, current week number, etc)"
Sure one need to take care to add all request parameter the jx depends on to the sitemap.
I do not want to judge which method is more error prone, both have their pros and cons.
>
> 3. I hardly see the point to make any JXTG customizations if you can do
> something like:
>
> <page
> jx:cache-key="${Packages.org.apache.cocoon.template.CocoonParametersCacheKeyBuilder.buildKey(
> cocoon.parameters )}" jx:cache-validity="${some validity}">
> <.../>
> </page>
>
> and
>
> public class CocoonParametersCacheKeyBuilder {
> public static String buildKey( Parameters parameters ) {
> // you probably need to sort cocoon parameters here so the order is
> // explicit
> StringBuffer buffer = new StringBuffer();
> String[] parameterNames = parameters.getNames();
> for ( int i = 0; i < parameterNames.length; ++i ) {
> String currentParameterName = parameterNames[ i ];
> if ( i > 0 )
> buffer.append( "&" );
> buffer.append( urlEncode( currentParameterName ) );
> buffer.append( "=" );
> buffer.append( urlEncode( parameters.getParameter(
> currentParameterName ) ) );
> }
> return buffer.toString();
> }
> }
>
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."
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)}
...
> 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.
salu2
--
thorsten
"Together we stand, divided we fall!"
Hey you (Pink Floyd)
Re: Caching jx *without* flow
Posted by Leszek Gawron <lg...@mobilebox.pl>.
Niels van Kampenhout wrote:
> Leszek Gawron wrote:
>> Thorsten Scherler wrote:
>>> Hi all, hi Ard,
>>>
>>> http://marc.theaimsgroup.com/?l=xml-cocoon-users&m=115194685214066&w=2
>>> "...
>>>>> Now, the cached jx would depend on these three parameters.
>>>> Very easy to use, and less error prone than the flow part.
>>>>> If somebody is interested in the code I will hear "
>>>
>>> Yes very interested.
>>> http://svn.apache.org/viewvc?view=rev&rev=446701
>>> https://issues.apache.org/jira/browse/FOR-931
>>>
>>> Can you attach a patch to this issue or commit it to cocoon directly?
>>>
>>> Would be awesome.
>> Do I get it right:
>>
>> you want to patch JXTG to automatically build up a cache key from
>> cocoon parameters?
>>
>> <map:match pattern="foo">
>> <map:generate src="foobar.jx">
>> <map:parameter name="foo" value="bar"/>
>> <map:parameter name="bar" value="foo"/>
>> </map:generate>
>> <map:serialize/>
>> </map:match>
>>
>> so cocoon:/foo gets cached with something like "foo=bar&bar=foo"?
>>
>> Why need a patch for that? After all you already have jx:cache-key and
>> jx:cache-validity.
>>
>
> Since Ard is on holiday until the GetTogether, I'll try to answer this
> question.
>
> The reason is, as Ard said, to make it less error prone. People easily
> make mistakes if they have to build a cachekey string themselves, en
> they also easily forget to actually put the jx:cache-key and
> jx:cache-validity attributes in the JX template. I am talking from
> experience!
>
> It also makes the code more readable/transparent/explicit, because you
> don't need the extra flow step anymore in many cases.
1. You don't need the extraflow step even right now. jx:cache-key and
jx:cache-validity works no matter what controller was used.
2. The solution you are proposing is error prone. The jx object model
does not get narrowed only to cocoon parameters so you are still able to
use cocoon.session, cocoon.request.
3. I hardly see the point to make any JXTG customizations if you can do
something like:
<page
jx:cache-key="${Packages.org.apache.cocoon.template.CocoonParametersCacheKeyBuilder.buildKey(
cocoon.parameters )}" jx:cache-validity="${some validity}">
<.../>
</page>
and
public class CocoonParametersCacheKeyBuilder {
public static String buildKey( Parameters parameters ) {
// you probably need to sort cocoon parameters here so the order is
// explicit
StringBuffer buffer = new StringBuffer();
String[] parameterNames = parameters.getNames();
for ( int i = 0; i < parameterNames.length; ++i ) {
String currentParameterName = parameterNames[ i ];
if ( i > 0 )
buffer.append( "&" );
buffer.append( urlEncode( currentParameterName ) );
buffer.append( "=" );
buffer.append( urlEncode( parameters.getParameter(
currentParameterName ) ) );
}
return buffer.toString();
}
}
We could probably add this class to cocoon-template block and provide
some samples. Still - nothing needs to be changed.
--
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
Re: Caching jx *without* flow
Posted by Niels van Kampenhout <n....@hippo.nl>.
Leszek Gawron wrote:
> Thorsten Scherler wrote:
>> Hi all, hi Ard,
>>
>> http://marc.theaimsgroup.com/?l=xml-cocoon-users&m=115194685214066&w=2
>> "...
>>>> Now, the cached jx would depend on these three parameters.
>>> Very easy to use, and less error prone than the flow part.
>>>> If somebody is interested in the code I will hear "
>>
>> Yes very interested.
>> http://svn.apache.org/viewvc?view=rev&rev=446701
>> https://issues.apache.org/jira/browse/FOR-931
>>
>> Can you attach a patch to this issue or commit it to cocoon directly?
>>
>> Would be awesome.
> Do I get it right:
>
> you want to patch JXTG to automatically build up a cache key from cocoon
> parameters?
>
> <map:match pattern="foo">
> <map:generate src="foobar.jx">
> <map:parameter name="foo" value="bar"/>
> <map:parameter name="bar" value="foo"/>
> </map:generate>
> <map:serialize/>
> </map:match>
>
> so cocoon:/foo gets cached with something like "foo=bar&bar=foo"?
>
> Why need a patch for that? After all you already have jx:cache-key and
> jx:cache-validity.
>
Since Ard is on holiday until the GetTogether, I'll try to answer this
question.
The reason is, as Ard said, to make it less error prone. People easily
make mistakes if they have to build a cachekey string themselves, en
they also easily forget to actually put the jx:cache-key and
jx:cache-validity attributes in the JX template. I am talking from
experience!
It also makes the code more readable/transparent/explicit, because you
don't need the extra flow step anymore in many cases.
Regards,
Niels
Re: Caching jx *without* flow
Posted by Leszek Gawron <lg...@mobilebox.pl>.
Thorsten Scherler wrote:
> Hi all, hi Ard,
>
> http://marc.theaimsgroup.com/?l=xml-cocoon-users&m=115194685214066&w=2
> "...
>>> Now, the cached jx would depend on these three parameters.
>> Very easy to use, and less error prone than the flow part.
>>> If somebody is interested in the code I will hear "
>
> Yes very interested.
>
> http://svn.apache.org/viewvc?view=rev&rev=446701
> https://issues.apache.org/jira/browse/FOR-931
>
> Can you attach a patch to this issue or commit it to cocoon directly?
>
> Would be awesome.
Do I get it right:
you want to patch JXTG to automatically build up a cache key from cocoon
parameters?
<map:match pattern="foo">
<map:generate src="foobar.jx">
<map:parameter name="foo" value="bar"/>
<map:parameter name="bar" value="foo"/>
</map:generate>
<map:serialize/>
</map:match>
so cocoon:/foo gets cached with something like "foo=bar&bar=foo"?
Why need a patch for that? After all you already have jx:cache-key and
jx:cache-validity.
--
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