Free for use: SaveFilesTransformer
Hi all, Available on wiki: http://wiki.apache.org/cocoon/SaveFilesTransformer It might be that someone else already wrote a Transformer like this one. It is derived from the SourceWritingTransformer (yet simplified) and has one important benefit over it: it can take a src attribute that can be used to capture also binary streams and save them to disk. Comments are welcome.. Kind regards, Geert Drs. G.P.H. Josten Consultant Daidalos BV Source of Innovation Hoekeindsehof 1-4 2665 JZ Bleiswijk Tel.: +31 (0) 10 850 1200 Fax: +31 (0) 10 850 1199 www.daidalos.nl KvK 27164984 De informatie - verzonden in of met dit emailbericht - is afkomstig van Daidalos BV en is uitsluitend bestemd voor de geadresseerde. Indien u dit bericht onbedoeld hebt ontvangen, verzoeken wij u het te verwijderen. Aan dit bericht kunnen geen rechten worden ontleend.
Re: cannot be in sitemap.xml anymore?
I find this problem is because of a bug at line 203 in org.apache.cocoon.core.container.spring.avalon.SitemapHelper, where classPathConfig shoud be passed as argument to method AvalonUtils.createConfiguration, intead of config. RiceOn 9/18/06, Rice Yeh <[EMAIL PROTECTED]> wrote: Hi, I tried the myBlock example with the latest trunk. jetty gets up successfully and I use browser to connect it. The following error message is shown on browser. Does it mean that cannot be in sitemap.xml anymore? I have removed, then it goes well.Unexpected element components at file:/C:/tmp/cocoon/yourBlock/target/yourBlock/sitemap.xmap:17:19 Rice
Re: [GT2006] 17 talks proposed!
Andrew Savory said the following on 18/9/06 17:38: Hi, Arje Cahn wrote: I agree with all of these. I also agree with Betrand to have the rest of Andrew's talks be written up on XML.com or similar. We missed out on the last round of articles that I proposed after the previous GT, so it might as well get beyond the idea stage this time. ... Just a thought; what about hacking together an article at the hackaton with a couple of people?? I'd be happy to join! Andrew? WDYT? It all sounds good - and doing the article during the hackathon would be a great way to contribute for those of us (me included) that never manage to close bugs ;-) Great! I'll help out. Bye, Helma
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:
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
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:
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: [GT2006] 17 talks proposed!
Hi, Arje Cahn wrote: I agree with all of these. I also agree with Betrand to have the rest of Andrew's talks be written up on XML.com or similar. We missed out on the last round of articles that I proposed after the previous GT, so it might as well get beyond the idea stage this time. ... Just a thought; what about hacking together an article at the hackaton with a couple of people?? I'd be happy to join! Andrew? WDYT? It all sounds good - and doing the article during the hackathon would be a great way to contribute for those of us (me included) that never manage to close bugs ;-) Thanks, Andrew. -- Andrew Savory, Managing Director, Luminas Limited Tel: +44 (0)870 741 6658 Fax: +44 (0)700 598 1135 Web: http://www.luminas.co.uk/ Orixo alliance: http://www.orixo.com/
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:
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: [GT2006] 17 talks proposed!
> > I think this is really awsome list of talks. > > What do you think?? > > GREAT! +100 Thanks :) > I agree with all of these. I also agree with Betrand to have > the rest of Andrew's talks be written up on XML.com or > similar. We missed out on the last round of articles that I > proposed after the previous GT, so it might as well get > beyond the idea stage this time. ... Just a thought; what about hacking together an article at the hackaton with a couple of people?? I'd be happy to join! Andrew? WDYT? Kind regards, Arjé Cahn Hippo Oosteinde 11 1017WT Amsterdam The Netherlands Tel +31 (0)20 5224466 www.hippo.nl [EMAIL PROTECTED] / [EMAIL PROTECTED] -- Hippo CMS release v6.03.05 is now available at www.hippocms.org --
Re: [GT2006] 17 talks proposed!
Arje Cahn said the following on 15/9/06 14:35: I think this is really awsome list of talks. What do you think?? GREAT! +100 "Things your mother never told you about Cocoon (The secret gems of Cocoon rebranded)" +1 wednesdaymorning "10 Reasons to use Cocoon" +1 wednesdaymorning "Cocoon reloaded: moving from xsp and actions to newer technologies" +1 for hackaton day 2 talk "Case studies" -1 (there's already a couple of them..) "An illustrated guide to Cocoon technologies" +1 (good fun to have in the morning sessions) "Cocoon archetypes (How to create a "typical" project with cocoon rebranded)" +0 I agree with all of these. I also agree with Betrand to have the rest of Andrew's talks be written up on XML.com or similar. We missed out on the last round of articles that I proposed after the previous GT, so it might as well get beyond the idea stage this time. Bye, Helma
Re: [M10N] Eclipse projects
Joerg Heinicke wrote: On 17.09.2006 14:38, Leszek Gawron wrote: Is this something we can influence at all? Is this a problem of the Maven Eclipse plugin? Or is everything left to the project wizard of Eclipse? Are you refering to maven eclipse plugin which you invoke by mvn eclipse:eclipse or to m2eclipse (which is an eclipse plugin for handling maven projects)? One is the Maven Eclipse plugin, the other one the Eclipse Maven plugin ;) I refer to Maven plugin invoked via eclipse:eclipse as described in our readme.txt or in Daisy. I've been having problems with this plugin too. Switched to m2eclipse. It is enough to refresh project after modifying pom.xml and new jars are automaticaly placed on classpath. -- 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:
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?
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:
jx:cache-key="${Packages.org.apache.cocoon.template.CocoonParametersCacheKeyBuilder.buildKey(
cocoon.parameters )}" jx:cache-validity="${some validity}">
<.../>
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
, or?
Or could I do
...
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
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?
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >> 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:
>
> jx:cache-key="${Packages.org.apache.cocoon.template.CocoonParametersCacheKeyBuilder.buildKey(
>
> cocoon.parameters )}" jx:cache-validity="${some validity}">
> <.../>
>
>
> 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
, or?
Or could I do
...
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-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?
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:
jx:cache-key="${Packages.org.apache.cocoon.template.CocoonParametersCacheKeyBuilder.buildKey(
cocoon.parameters )}" jx:cache-validity="${some validity}">
<.../>
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
Thorsten Scherler wrote: that is the normal file generator which is indeed cacheable. I am talking about which is not cacheable (if not changed since the last update of the cocoon in forrest). I am sorry - it should of course state src="foobar.jx"> JXTG IS cacheable if you provide jx:cache-key and jx:cache-validity in template body. 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
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? > > > > > > > > > > > > > > > > > > > > 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 '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
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?
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:
jx:cache-key="${Packages.org.apache.cocoon.template.CocoonParametersCacheKeyBuilder.buildKey(
cocoon.parameters )}" jx:cache-validity="${some validity}">
<.../>
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 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? > > > that is the normal file generator which is indeed cacheable. I am talking about which is not cacheable (if not changed since the last update of the cocoon in forrest). > > > > > > > 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
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? 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
