Correct. InvokeOnComponent is most helpful when you KNOW you only need to run a limited lifecycle, but for a generic case, the entire component tree should be processed. Things like A4J can take advantage of the fact that only items in the AJAX regions need to be processed but Trinidad was not designed that way. Might be nice to add such a boundry at some point. :)
On Sat, Apr 26, 2008 at 8:30 AM, Andrew Robinson < [EMAIL PROTECTED]> wrote: > That brings up problems with rendereds being skipped. Things like > tr:form need to be called. We could work around this but we can't just > slap in invokeOnComponent > > On 4/26/08, Matthias Wessendorf <[EMAIL PROTECTED]> wrote: > > On Wed, Apr 23, 2008 at 6:16 PM, Andrew Robinson > > <[EMAIL PROTECTED]> wrote: > > > Just a quick reply: > > > > > > 1) yes PPR is a full JSF request > > > > in the JSF 1.2 world, we could have an optimized JSF lifecycle (when > doing > > PPR). > > -identify all "ajax" components. > > -call invokeoncomponent only for them and have a special callback (for > > the particular phases) > > to call the lifecycle methods (processXzy()) only on the "ajax" > components > > > > > 2) Trinidad can cache the UIViewRoot on the server with its "hack" of > > > forcing client side state to use server side state with a client > token > > > 3) JSF 2.0 EG is currently discussing AJAX and state saving problems. > > > Lets hope they have an epiphany > > > 4) You could attempt to write a custom state manager if you don't > want > > > Trinidad's view caching but want to optimize PPR requests > > > > > > -Andrew > > > > > > > > > > > > On Wed, Apr 23, 2008 at 2:34 AM, Renzo Tomaselli > > > <[EMAIL PROTECTED]> wrote: > > > > Hi, I noticed that a PPR cycle deals with fully-populated JSF > phases. > > In > > > > other words - the entire view is restored, rendered and saved - > > although > > > > what is actually sent back to the client depends on current PPR > > targets, > > > > which might be even totally missing. > > > > The resource gain of PPR concerns less stuff returned to the client > and > > > > less DOM to update - but the business layer is fully involved as > for > > > > full-page requests. > > > > For industrial applications this is usually the most significant > cost. > > > > Is this behavior a Trinidad-specific one, a side-effect of Ajax-JSF > > > > coupling or anything which could be improved ? > > > > I guess the hard point here is to wire PPR targets to subviews to > > > > restore/render/save, but oops ! AFAIK such a concept doesn't even > exist > > > > in JSF. > > > > There are just "views". So we must face full view handling in any > case. > > > > I was considering to be lazy in bean rendering for PPR - but it > can't > > > > work - what is saved is what we will restore next time - whether > PPR or > > > > full. No way. > > > > Any comment is welcome. > > > > > > > > -- Renzo > > > > > > > > > > > > > > > > > > > > > > > -- > > Matthias Wessendorf > > > > further stuff: > > blog: http://matthiaswessendorf.wordpress.com/ > > sessions: http://www.slideshare.net/mwessendorf > > mail: matzew-at-apache-dot-org > > >
