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 13:20:40 GMT


> -----Ursprungliche Nachricht-----
> Von: dev-return-61751-m_rolappe=web.de@cocoon.apache.org
> [mailto:dev-return-61751-m_rolappe=web.de@cocoon.apache.org]Im Auftrag
> von Leszek Gawron
> Gesendet: Mittwoch, 2. Juni 2004 14:21
> An: dev@cocoon.apache.org
> Betreff: Re: AW: JXTG and caching
>
>
> Marco Rolappe wrote:
> >>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.
> Imagine that you have a view that is constructed out of several
> aggregates
> (nested to be harder). Every aggregation part has it's own
> validity so while
> preparing data you would have to consider the exact view composition and
> generate view for those parts which already expired. Not so much SoC IMO.

composite view would imply composite validity, so I don't see a problem.
still SoC IMO ;-)

> >>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?
> And end up like XSP did ? :)

yeah, that was the 'plan' ;-) why SoC if you can do it all in one place?


Mime
View raw message