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 15:23:56 GMT


> -----Ursprungliche Nachricht-----
> Von: dev-return-61756-m_rolappe=web.de@cocoon.apache.org
> [mailto:dev-return-61756-m_rolappe=web.de@cocoon.apache.org]Im Auftrag
> von Leszek Gawron
> Gesendet: Mittwoch, 2. Juni 2004 15:37
> An: dev@cocoon.apache.org
> Betreff: Re: AW: JXTG and caching
>
>
> 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

don't know exactly what you mean with aggregation here. <map:aggregate>
stuff?

> cached view only
> if all parts were still valid it would be hardly usable. If you make it

if you're talking about <map:aggregate> stuff the aggregate would be
'invalid'. the still valid parts wouldn't have to be regenerated, tough.
thus, only the invalid parts and the aggregate would have to be regenerated.

> complex the controller needs to know which data to prepare so it
> has to know
> view rendering details which breaks SoC IMO.

hard to discuss without a concrete exmaple. another point to note is the
difference between caching the view data/bizdata and the cacheability of the
pipeline stage; providing JXTG with a key and validity is the one side, i.e.
telling the pipeline infrastructure whether the cached artifact is still
valid or has to be regenerated. the other side is the validity of your
prepared view data (heavy business stuff), which is a different issue. but
it's also straightforward and should go something like this:

- controller looks up cached data (view data/heavy business stuff)
- if cache entry exists check validity
	- if valid
		- 'send' cached view data and validity to flow context
	- if invalid
		- prepare view data
		- cache view data
		- 'send' view data and validity to flow context
- if cache entry doesn't exist
	- prepare view data
	- cache view data
	- 'send' view data and validity to flow context


Mime
View raw message