cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Leszek Gawron <lgaw...@mobilebox.pl>
Subject Re: AW: JXTG and caching
Date Wed, 02 Jun 2004 13:36:49 GMT
Marco Rolappe wrote:
> 
>>-----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 ;-)
see my example of heavy biz data preparation. Suppose every aggregation part 
needs another part of bizData. If you make it simple and show cached view only 
if all parts were still valid it would be hardly usable. If you make it 
complex the controller needs to know which data to prepare so it has to know 
view rendering details which breaks SoC IMO.


-- 
Leszek Gawron

Mime
View raw message