cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Marco Rolappe" <m_rola...@web.de>
Subject AW: JXTG and caching
Date Wed, 02 Jun 2004 11:54:48 GMT


> -----Urspr√ľngliche Nachricht-----
> Von: dev-return-61743-m_rolappe=web.de@cocoon.apache.org
> [mailto:dev-return-61743-m_rolappe=web.de@cocoon.apache.org]Im Auftrag
> von Upayavira
> Gesendet: Mittwoch, 2. Juni 2004 11:52
> An: dev@cocoon.apache.org
> Betreff: Re: JXTG and caching
>

<snip/>

> Remember, the jxtemplate pulls the validity from the business object.
> The flow doesn't need to even know that caching might be happening (and
> in fact _shouldn't_ know it is happening). If you have to write
> flowscript to deal with this, then something is probably wrong.

that's what I don't get/where I disagree. flow is supposed to be the
controller, isn't it? the controller is supposed to act as a mediator
between the model and the view. I don't think that the view (jxt) should be
responsible for model cacheability, but the controller should be. the
controller is the one to know about the model and to prepare/populate the
view. this also means the controller is the best place to handle the
cacheability because it knows which data/part of the model is relevant.

>
> If your business object takes an age to instantiate, and you can decide
> whether or not to instantiate it based upon request parameters, then
> wrap it in a lighter component that does (in pseudocode):

IMO that's what the controller would be supposed to do; just like preparing
the bizData and 'sending' it to the flow context, it would determine the
caching info and send it to the flow context. then JXT would use the bizdata
and accompanying cache info from the flow context. SoC IMO.

>
> lightObject.getValidity() {
>   return request.parameters["a"]+ request.parameters["b"];
> }
>
> lightObject.getHeavyBusinessObject() {
>   if (this.heavyBusinessObject == null) {
>      this.heavyBusinessObject = HeavyBusinessObjectBuilder.newObject();
>   }
>   return this.heavyBusinessObject;
> }
>
> Then, in your jxt, you use Sylvains
> jx:cacheKey="lightObject.getValidity()" construct, and then later in
> your jxt, you access your heavy object with
> #{/lightObject/HeavyObject/property1}. This latter expression will only
> be invoked if the page is not cached.
>
> Does that make sense?
>
> It seems to me that Sylvains suggested extension of jxt has a great deal
> of power in it.

yeah, why don't introduce jx:logic so we can do it directly in the template?


Mime
View raw message