myfaces-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Andrew Robinson" <andrew.rw.robin...@gmail.com>
Subject Re: [Trinidad] about the cost of PPR
Date Sat, 26 Apr 2008 14:30:42 GMT
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 <matzew@apache.org> wrote:
> On Wed, Apr 23, 2008 at 6:16 PM, Andrew Robinson
> <andrew.rw.robinson@gmail.com> 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
> >  <renzo.tomaselli@tecnotp.it> 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
>

Mime
View raw message