> -----Ursprungliche Nachricht----- > Von: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] Auftrag > von Leszek Gawron > Gesendet: Mittwoch, 2. Juni 2004 14:21 > An: [EMAIL PROTECTED] > 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?
