RE: Caching jx *without* flow
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-parameterstrue/use-sitemap-parameters
use-request-parameterstrue/use-request-parameters
use-request-attributestrue/use-request-attributes
use-session-parametersfalse/use-session-parameters
use-cookie-parametersfalse/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 sorry as wellbut as was mentioned, I was on holiday untill this
morning, so now, after being awake for 34 hours, have had a terrible flight and
now spitting through 2782 unread mails, I will try to give my to cents about it:
First of all, there are two types of caching things which tend to get mixed up
in the thread all along:
1) The jx:import, in which a change does not get picked up without re-saving
the parent (main) one. According the TraxTransformer, we could, depending on
the check-includes parameter, include the validity objects of the imported
templates (if it should work for imports importing a template, then it should
be recursive, implying perhaps a small performance decrease for initial runs).
In xsl it works with specifying setting the check-includes to true. Then,
changing an imported xsl, will work without saving the main. The problem
remains for an imported xsl in an imported xsl, because the validities are not
added recursively, but only one level deep (not to hard to fix either I think,
see my comment in http://issues.apache.org/jira/browse/COCOON-1909, but it is
not part of cocoon). Or, we leave it the way it is like now, and let people
save the main template after changing an imported one.
2) The cachekey created. Actually, this is the only one affected by the
suggested patch for the JXTG, and is independant of the former one. Leszek
seems to be wondering why it is needed. After all, he showed (by the way quite
cool way) how to just put it in the jx template, like
page
jx:cache-key=${Packages.org.apache.cocoon.template.CocoonParametersCacheKeyBuilder.buildKey(
cocoon.parameters )} jx:cache-validity=${some validity}
.../
/page
and add a CocoonParametersCacheKeyBuilder class. This works, only, it is hard
to specifiy which parameters you want and do not want. Also, how to include for
example one specific session value you want the cache to depend on, or the
current date. This means, adding multiple static buildKey 's, or overload it
or whatever. But then, why does it not work like this for the TraxTransformer
by default? That you add your own CocoonParametersCacheKeyBuilder, and build
the keys? There is a very simple reason, and that is, that it is just way
easier to just include the sitemap parameters (assuming all the parameters in
configuration are set to false, which is almost always the case: I mailed
already many many times to the user list: *always* set
use-request-parametersfalse/use-request-parameters for your
TraxTransformer. Crawlers tend to come along with arbitrary parameters, blowing
up your cache and leaving it with unreacheable cachekeys). The reason the
TraxTransformer by default puts in its cachekey all sitemap parameters is that
it is *very* easy: you can hardly make an error!
And this is the exact reason, that it is nice to have a way, to have by default
added to the cachekey the sitemap parameters defined in the JXTG. It is exactly
the same as for the TraxTransformer. Only difference, is that for the
TraxTransformer, you *need* to have them passed in as sitemap parameters to
have them available in the xsl, so you cannot forget one. For the suggested
JXTG, you have to think about them, and not forget. I do agree, that
jx:includeInKey and jx:excludeFromKey are completely redundant, and therefor
probably also never used.
Then, there might be an argument, that the jx template is to dynamic to have it
cached on simple sitemap parameters. Leszek states The jx object model
does not get narrowed only to cocoon parameters so you are still able to use
cocoon.session, cocoon.request, although these two examples are easily added
to sitemap parameters (you know on which ones the cache depends). The caching
becomes impossible when you use operations in your jx template, and have
outcomes, that cannot be known at sitemap level. Well, in that case, probably,
do you want caching at all? Use a parameter like Antonio suggests. Don't
forget, that implicitely, the very same assumtion is made for the
TraxTransformer. You can easily use xslt extensions, with date functions, which
do not get included in the cachekey/validity, implying faulty behavior. This
also implies, that using the very neat i18n:date pattern=MMdd/ in an
xsl, which gets translated by the
Re: Caching jx *without* flow
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-parameterstrue/use-sitemap-parameters use-request-parameterstrue/use-request-parameters use-request-attributestrue/use-request-attributes use-session-parametersfalse/use-session-parameters use-cookie-parametersfalse/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
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
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=revrev=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-parametersfalse/use-request-parameters use-session-parametersfalse/use-session-parameters use-cookie-parametersfalse/use-cookie-parameters xslt-processor-rolexalan/xslt-processor-role check-includestrue/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-parameterstrue/use-sitemap-parameters use-request-parameterstrue/use-request-parameters use-request-attributestrue/use-request-attributes use-session-parametersfalse/use-session-parameters use-cookie-parametersfalse/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
Leszek Gawron wrote: Thorsten Scherler wrote: Hi all, hi Ard, http://marc.theaimsgroup.com/?l=xml-cocoon-usersm=115194685214066w=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=revrev=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=barbar=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
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-usersm=115194685214066w=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=revrev=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=barbar=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
Niels van Kampenhout wrote:
Leszek Gawron wrote:
Thorsten Scherler wrote:
Hi all, hi Ard,
http://marc.theaimsgroup.com/?l=xml-cocoon-usersm=115194685214066w=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=revrev=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=barbar=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
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-usersm=115194685214066w=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=revrev=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=barbar=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=revrevision=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=446701r2=447311pathrev=447311diff_format=h TIA salu2 Regards, Niels -- thorsten Together we stand, divided we fall! Hey you (Pink Floyd)
Re: Caching jx *without* flow
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=barbar=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
Leszek Gawron wrote:
Niels van Kampenhout wrote:
Leszek Gawron wrote:
Thorsten Scherler wrote:
Hi all, hi Ard,
http://marc.theaimsgroup.com/?l=xml-cocoon-usersm=115194685214066w=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=revrev=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=barbar=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
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-usersm=115194685214066w=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=revrev=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=barbar=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
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:/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
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:/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
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:/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
Thorsten Scherler wrote: Hi all, hi Ard, http://marc.theaimsgroup.com/?l=xml-cocoon-usersm=115194685214066w=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=revrev=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=barbar=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
