RE: Caching jx *without* flow
> > Leszek Gawron escribió: > > If user wants to make JXTG automatically cacheable he/she must > > explicitly state it in configuration: > > > > > > > > true > > true > > true > > false > > false > > > > > 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 <.../> 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 false 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 in an xsl, which gets translated by the I18n transformer to the current date, won't work!! Simply, because on the next day, the validity and cachekey both might be unchanged. If you want this, you should use a sitemap parameter like and use in the xsl sometihng like So, I suggest to copy the TraxTransformer way into the JXTG, which already contains some assumptions (and people tend to work with it quite smooth, hardly ever realizing some small pitfalls). Hope that despite my holiday state of mind and 34 hours without sleep did not result in uncomprehensable
Re: Caching jx *without* flow
Leszek Gawron escribió: If user wants to make JXTG automatically cacheable he/she must explicitly state it in configuration: true true true false false 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: Or somehow to overwrite the default configuration when we call the generator. Makes sense? Best Regards, Antonio Gallardo.
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=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 . 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). 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: pool-max="32" src="org.apache.cocoon.transformation.TraxTransformer"> false false false xalan true If user wants to make JXTG automatically cacheable he/she must explicitly state it in configuration: true true true false false 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
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 > > , or? > > > > Or could I do > > > > ... > > 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 . 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). 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 [EMAIL PROTECTED][EMAIL PROTECTED]
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
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: 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: 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
Re: Caching jx *without* flow
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. -- 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
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)