> > Leszek Gawron escribió: > > If user wants to make JXTG automatically cacheable he/she must > > explicitly state it in configuration: > > > > <map:generator src="org.apache.cocoon.template.JXTemplateGenerator"> > > <automatic-cache-key> > > <use-sitemap-parameters>true</use-sitemap-parameters> > > <use-request-parameters>true</use-request-parameters> > > <use-request-attributes>true</use-request-attributes> > > <use-session-parameters>false</use-session-parameters> > > <use-cookie-parameters>false</use-cookie-parameters> > > </automatic-cache-key> > > </map:generator> > Hi Leszek, > > Sorry to join the party too late. I have been busy the last > months, but > I am still alive. :-)
I am sorry as well....but 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-parameters>false</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="yyyyMMdd"/> 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 <map:parameter name="date" value="{date:yyyyMMdd}"/> and use in the xsl sometihng like <i18n:date src-pattern="yyyyMMdd" pattern="yyyyMMdd" value="${date}"/>.... 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 rubbish :-) Regards Ard > > 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. > > >
