On Mon, Dec 10, 2012 at 12:09 PM, Leonardo Uribe <lu4242_at_gmail.com> wrote:
> Hi
>
> I have been thinking for a while about this feature and I think it is
> a very interesting idea.
>
> In theory, all components knows how to render themselves fully,
> but in this case, the component needs to know how to render only
> the parts that changes dynamically. So, there is a part of the
> rendered markup that does not change across requests and other
> parts that do so.
>
The key here isn't the markup, though. The idea is that markup may not even
be sent to update the component. If it's just property changes, it's faster
to send JSON with the property values and have the component update itself
via JavaScript.
>
> The interesting part is what happens if we can take advantage of
> PSS algorithm to know which parts changes dynamically
> (properties bound to value expressions or with changes into its
> delta state) and which ones does not.
>
> In this moment, it is difficult to do that with the current spec,
> because there is no access to which properties has changes in the
> delta state, but we can check if a property relies on a
> ValueExpression/ValueBinding to derive its value.
>
How hard would it be to expose that info?
>
> It suppose to "teach" component renderers how to render themselves
> in ajax case using "partial DOM updates", and put another code in
> the javascript side to resolve the changes and apply them. This is
> an additional contract for component/renderers, but in some point,
> both of them should work together.
>
Correct -- basically as long as a component has a standard JS hook it can
apply instead of the default DOM update (or even in addition to it), we
effectively allow the JS code and the JSF renderer to define their own
contract. PrimeFaces already allows such a hook on the client, btw.
> regards,
>
> Leonardo Uribe
>
>
> 2012/11/28 Kito Mann <kito.mann_at_virtua.com>:
> > On Wed, Nov 28, 2012 at 5:42 PM, Neil Griffin
> > <neil.griffin_at_portletfaces.org> wrote:
> >>
> >> Hi Kito,
> >>
> >> This sounds interesting -- just curious, are you experiencing the same
> >> performance troubles equally with Mojarra and MyFaces?
> >>
> >> Neil
> >>
> >
> > The implementation doesn't matter -- this is a spec issue. For example,
> > let's say you're rendering an input control in response to an Ajax
> request.
> > Only the value property has changed. Right now, JSF will re-render the
> > entire component, including all of its markup, and then replace that
> element
> > in the browser's DOM. Instead, we could send JSON with the single
> property,
> > and the component could update itself based on that property. (Or JSF
> could
> > handle components in a standard way but allow components to override that
> > behavior or opt-out altogether.) For more complex components (and this
> > includes CSS-based input widgets that replace the standard JSF input
> > controls), the result is decreased bandwidth consumption and more
> responsive
> > UI changes.
> >
> >
> >>
> >> On Nov 28, 2012, at 5:40 PM, Kito Mann <kito.mann_at_virtua.com> wrote:
> >>
> >> Hey guys,
> >>
> >> It looks like I sent this to the wrong place. Thanks for the heads up,
> >> Andy!
> >>
> >>
> >> On Tue, Nov 13, 2012 at 7:38 PM, Kito Mann <kito.mann_at_virtua.com>
> wrote:
> >>>
> >>> Hello volunteers,
> >>>
> >>> One of the primary complaints about JSF is speed. We have paid a lot
> >>> of attention to optimizing server-side state over the past few years,
> >>> but we can also optimize the processing on the client. When a
> >>> component is updated via Ajax, currently we render the entire
> >>> component, even if only one property has changed. It would be much
> >>> more efficient if we sent only the changed properties via JSON and let
> >>> the client-side representation of the component update itself
> >>> accordingly. I have implemented a limited version of this for one of
> >>> my clients, and Ajax updates are noticeably faster. Updating the spec
> >>> to support this would not be a major change (because components would
> >>> opt-in to this feature), but it would have a dramatic affect on
> >>> client-side Ajax updates.
> >>>
> >>> I have been meaning to write a formal proposal for a while, but I
> >>> figured I should at least share my thinking first.
> >>>
> >>> Thoughts?
> >>>
> >>> Sent from my iPhone
> >>>
> >>> http://www.jsfcentral.com
> >>> http://www.Virtua.com
> >>
> >>
> >>
> >>
> >>
> >
>