Mailing-List: contact dev-help@cocoon.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@cocoon.apache.org
Received-SPF: neutral (asf.osuosl.org: local policy)
Subject: Re: Caching jx *without* flow
From: Thorsten Scherler <thorsten@apache.org>
To: dev@cocoon.apache.org
In-Reply-To: <450E5340.2030804@mobilebox.pl>
References: <1158349311.17986.4.camel@localhost>
	 <450D361D.1070407@mobilebox.pl> <450E4BE7.40103@hippo.nl>
	 <450E5340.2030804@mobilebox.pl>
Content-Type: text/plain
Date: Mon, 18 Sep 2006 10:57:05 +0200
Message-Id: <1158569825.4930.34.camel@localhost>
Mime-Version: 1.0
Content-Transfer-Encoding: 7bit

On Mon, 2006-09-18 at 10:05 +0200, Leszek Gawron wrote:
> Niels van Kampenhout wrote:
> > Leszek Gawron wrote:
> >> Thorsten Scherler wrote:
> >>> Hi all, hi Ard,
> >>>
> >>> http://marc.theaimsgroup.com/?l=xml-cocoon-users&m=115194685214066&w=2
> >>> "...
> >>>>> Now, the cached jx would depend on these three parameters. 
> >>>> Very easy to use, and less error prone than the flow part.
> >>>>> If somebody is interested in the code I will hear "
> >>>
> >>> Yes very interested.
> >>> http://svn.apache.org/viewvc?view=rev&rev=446701
> >>> https://issues.apache.org/jira/browse/FOR-931
> >>>
> >>> Can you attach a patch to this issue or commit it to cocoon directly?
> >>>
> >>> Would be awesome.
> >> Do I get it right:
> >>
> >> you want to patch JXTG to automatically build up a cache key from 
> >> cocoon parameters?
> >>
> >> <map:match pattern="foo">
> >>   <map:generate src="foobar.jx">
> >>     <map:parameter name="foo" value="bar"/>
> >>     <map:parameter name="bar" value="foo"/>
> >>   </map:generate>
> >>   <map:serialize/>
> >> </map:match>
> >>
> >> so cocoon:/foo gets cached with something like "foo=bar&bar=foo"?
> >>
> >> Why need a patch for that? After all you already have jx:cache-key and 
> >> jx:cache-validity.
> >>
> > 
> > Since Ard is on holiday until the GetTogether, I'll try to answer this 
> > question.
> > 
> > The reason is, as Ard said, to make it less error prone. People easily 
> > make mistakes if they have to build a cachekey string themselves, en 
> > they also easily forget to actually put the jx:cache-key and 
> > jx:cache-validity attributes in the JX template. I am talking from 
> > experience!
> > 
> > It also makes the code more readable/transparent/explicit, because you 
> > don't need the extra flow step anymore in many cases.
> 
> 1. You don't need the extraflow step even right now. jx:cache-key and 
> jx:cache-validity works no matter what controller was used.
> 
> 2. The solution you are proposing is error prone. The jx object model 
> does not get narrowed only to cocoon parameters so you are still able to 
> use cocoon.session, cocoon.request.

Hmm, that is why Ard wrote:
"> > now, to var ck you append the things that is depends on 
> (like a request parameter, current week number, etc)"

Sure one need to take care to add all request parameter the jx depends on to the sitemap. 
I do not want to judge which method is more error prone, both have their pros and cons.

> 
> 3. I hardly see the point to make any JXTG customizations if you can do 
> something like:
> 
> <page 
> jx:cache-key="${Packages.org.apache.cocoon.template.CocoonParametersCacheKeyBuilder.buildKey( 
> cocoon.parameters )}" jx:cache-validity="${some validity}">
> <.../>
> </page>
> 
> and
> 
> public class CocoonParametersCacheKeyBuilder {
>    public static String buildKey( Parameters parameters ) {
>      // you probably need to sort cocoon parameters here so the order is
>      // explicit
>      StringBuffer buffer = new StringBuffer();
>      String[] parameterNames = parameters.getNames();
>      for ( int i = 0; i < parameterNames.length; ++i ) {
>          String currentParameterName = parameterNames[ i ];
>          if ( i > 0 )
>            buffer.append( "&" );
>          buffer.append( urlEncode( currentParameterName ) );
>          buffer.append( "=" );
>          buffer.append( urlEncode( parameters.getParameter(
>                                    currentParameterName ) ) );
>      }
>      return buffer.toString();
>    }
> }
> 

Hmm, maybe the documentation is outdated but
http://cocoon.apache.org/2.1/userdocs/flow/jxtemplate.html state "When
used inside flow, JXTemplate has access to Java and can therefore
evaluate expressions like "java.util.Date()" or "java.util.HashMap()".
This does NOT work when JXTemplates are used without flow."

Wouldn't that mean that the example would not work without flow?

Further regarding the validity as I understand your example this would
not allow to use an AggregatedValidity which would be extended for all
<jx:import/>, or? 

Or could I do 
<jx:set var="validity" value="new AggregatedValidity()"/> 
...
<jx:set var="validity" value="${validity.add(importValidity)}
...

> We could probably add this class to cocoon-template block and provide 
> some samples. Still - nothing needs to be changed.

Yeah that would be awesome. Still I am not sure whether the forrest
community would accept the inline solution. I understand your point
though, but under the user perspective I am with Niels.

salu2
-- 
thorsten

"Together we stand, divided we fall!" 
Hey you (Pink Floyd)