Hi Alex,
just updated all commits and test your ItemRenderer and is not working, do
you know what could be?
The project 'App' has been successfully compiled and optimized.
/Users/carlosrovira/Dev/Flex/source/flexjs/flex-asjs/examples/flexjs/MDLExample/src/main/flex/itemRenderers/CustomListItemRenderer.mxml(28):
col: 12 Data binding will not be able to detect assignments to 'label'.
text="{data.label}" >
^
[INFO]
------------------------------------------------------------------------
[INFO] BUILD FAILURE
2016-12-09 16:25 GMT+01:00 Alex Harui <aha...@adobe.com>:
>
>
> 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
>
>
--
Carlos Rovira
Director General
M: +34 607 22 60 05
http://www.codeoscopic.com
http://www.avant2.es
Este mensaje se dirige exclusivamente a su destinatario y puede contener
información privilegiada o confidencial. Si ha recibido este mensaje por
error, le rogamos que nos lo comunique inmediatamente por esta misma vía y
proceda a su destrucción.
De la vigente Ley Orgánica de Protección de Datos (15/1999), le comunicamos
que sus datos forman parte de un fichero cuyo responsable es CODEOSCOPIC
S.A. La finalidad de dicho tratamiento es facilitar la prestación del
servicio o información solicitados, teniendo usted derecho de acceso,
rectificación, cancelación y oposición de sus datos dirigiéndose a nuestras
oficinas c/ Paseo de la Habana 9-11, 28036, Madrid con la documentación
necesaria.
