Just a quick reply: 1) yes PPR is a full JSF request 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 > > >
