On 12/9/16, 5:35 AM, "carlos.rov...@gmail.com on behalf of Carlos Rovira"
<carlos.rov...@gmail.com on behalf of carlosrov...@apache.org> wrote:
>Hi
>
>I need to know how to deal with data binding in different situations,
>ItemRenderer, View, Container, Component, Bead,...
>
>I saw various classes ConstantBinding, ViewBeadBinding...
>
>Hope someone could share the main principles of Binding in FlexJS
Binding in the regular Flex SDK is extremely wasteful. That's why we
often see folks recommend that you start taking out data bindings when you
have performance issues. Flex Mobile default item renderers are written
in AS instead of MXML for that reason. Binding in general has to
"highly-sensitive". It needs to look for all kinds of possible change
conditions, such as the source or destination being changed as well as the
property on the source being changed. In the regular Flex SDK, this
highly-sensitive detection mechanism is used everywhere you use binding
expressions.
in FlexJS, we want to have different implementations based on certain
scenarios. There are classes named XXXDataBinding (vs YYYBinding) that
implement a change detection mechanism specific to that scenario. So
ViewDataBinding knows that most data bindings will probably be from the
applicationModel property to various controls. The various XXXDataBinding
implementations use the YYYBinding classes like ConstantBinding and
SimpleBinding to optimize for certain patterns that don't require as much
overhead to set up. There is a GenericBinding for everything else. Also,
having a choice of YYYBinding classes allows the developer to not use {}
expressions and simply add a YYYBindingClass as a bead and get binding to
work without the overhead of the compiler setting up a data structure for
the XXXDataBindingClass to interpret at instantiation time. So, this is
another example of PAYG. You can be lazy and have the compiler and
framework figure out what to do with a {} expression, or you can save code
by manually implementing it, or you can save even more by writing AS to
addEventListener for the right thing at the right time.
Anyway, you mentioned ItemRenderer above, and I found out yesterday that
ItemRenderer binding needed its own implementation. It can take advantage
of knowing that if you bind to data.something, that there is no need to
set change detection for the source or destination objects. It knows that
the only trigger is when in the item renderer lifecycle, the data property
is set. I just pushed that change. Now my renderer looks like:
<js:MXMLItemRenderer xmlns:fx="http://ns.adobe.com/mxml/2009";
xmlns:js="library://ns.apache.org/flexjs/basic"
width="100%">
<js:beads>
<js:VerticalLayout />
<js:ItemRendererDataBinding />
</js:beads>
<js:Label width="100%" height="30" style="fontWeight:bold"
text="{data.qname}" >
</js:Label>
<js:MultilineLabel id="description" width="100%"
text="{data.description}" />
</js:MXMLItemRenderer>
HTH,
-Alex
