> -----Ursprungliche Nachricht----- > Von: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] Auftrag > von Leszek Gawron > Gesendet: Mittwoch, 2. Juni 2004 19:46 > An: [EMAIL PROTECTED] > Betreff: Re: AW: JXTG and caching > > > > 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 ?
a cache entry with a composite validity (AggregatedValidity). > > - 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 regarding efficiency you always have to make tradeoffs between processing (time) and memory. it also depends on the data's relevance (how often requested, etc.) and other factors. > - it is double caching really (if you cache the view also) well, it's hard to decide for the general case. if the preparation is the biggest overhead I'd have only that cached and the view not. > - 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. well, we have different mindsets regarding template usage. for me a template should be just a template; template data with holes in it to fill. following MVC the model should be agnostic of the view and the view should be agnostic of the model. the controller is the one who has all the knowledge. I don't like my view to depend on *implementation* details, then it really gets messy. anyway, the approach works well for me and I haven't yet stumbled over the problems you encountered. > > - '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? well, you're completely free how granular your cache validity information is. solely depends on your object model.
