Hi
LU >> In theory, all components knows how to render themselves fully,
LU >> but in this case, the component needs to know how to render only
LU >> the parts that changes dynamically. So, there is a part of the
LU >> rendered markup that does not change across requests and other
LU >> parts that do so.
KM > The key here isn't the markup, though. The idea is that markup may not even
KM > be sent to update the component. If it's just property changes, it's faster
KM > to send JSON with the property values and have the component update itself
KM > via JavaScript.
Yes, I know that. But note the assumption over the markup is critical. Suppose
you have an input text field and the you have two ValueExpression set to style
and value properties, but the other properties and structure are just static
markup. To update it correctly, it is necessary to send always the result
of the evaluation of value and style properties, because it is assumed other
parts of the component does not change. The logic that decides what is
necessary to update should be in the Renderer, because it is the only one
who knows the layout of the markup and the correspondence between the
component properties and the markup.
LU >> The interesting part is what happens if we can take advantage of
LU >> PSS algorithm to know which parts changes dynamically
LU >> (properties bound to value expressions or with changes into its
LU >> delta state) and which ones does not.
LU >>
LU >> In this moment, it is difficult to do that with the current spec,
LU >> because there is no access to which properties has changes in the
LU >> delta state, but we can check if a property relies on a
LU >> ValueExpression/ValueBinding to derive its value.
KM > How hard would it be to expose that info?
Just a couple of methods in StateHelper/UIComponent will do the trick. The
problem here is you really want to do this change in the spec, because
otherwise you need to provide a custom StateHelper and inject it changing
the component hierarchy, and that's not nice.
LU >> It suppose to "teach" component renderers how to render themselves
LU >> in ajax case using "partial DOM updates", and put another code in
LU >> the javascript side to resolve the changes and apply them. This is
LU >> an additional contract for component/renderers, but in some point,
LU >> both of them should work together.
KM > Correct -- basically as long as a component has a standard JS hook it can
KM > apply instead of the default DOM update (or even in addition to it), we
KM > effectively allow the JS code and the JSF renderer to define their own
KM > contract. PrimeFaces already allows such a hook on the client, btw.
Let's suppose we want to allow JSF component libraries to implement this trick
in JSF (I know time's up for JSF 2.2, but anyway ... ) What do we need to do?
1. Provide a way to check which properties has delta attached or are bound to
a ValueExpression.
2. Fix RendererWrapper problem. In this case, this feature is just
another contract
that you can add to a renderer. But if you create a renderer wrapper,
you want to
specify in some way that the renderer implements the contract too. It is similar
to the problem with @ListenerFor annotation, because classes annotated
with @ListenerFor implements ComponentSystemEventListener, so a wrapper should
implement Renderer and ComponentSystemEventListener.
regards,
Leonardo