Marco Rolappe wrote:
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?
yes
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.
you're right but I am talking also about biz data provided from flow.
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;
this is what I've been talking from the start. That is why we did not
understand each other.
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)
For view data this may not be a single cache entry (map:aggregate). what
then ?
- 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
I think cocoon should not cache biz data because:
- it may be memory consuming
- it is double caching really (if you cache the view also)
- you mess with lazily fetched collections(hibernate, ojb):
* collections retrieve data from backend during view rendering
* only the needed data is being fetched so you would have to know
EXACTLY what data the view needs and initialize it before caching.
This way all the fun of using OR (hibernate) and templates is
destroyed. When you have a object model with lazy fetching support
you can extend your view without making ANY changes to the
controller code as the model gives you access to much more data that
you need at the moment.
- 'send' view data and validity to flow context
- if cache entry doesn't exist
- prepare view data
Which part of view data? If your full view data consists of 100 DB
fetches and only the part that uses 2 has expired? How would you detect
that?
- cache view data
- 'send' view data and validity to flow context
My regards
LG
