Well, there isn't any dataChange property being dispatched, but the
ItemRendererDataBinding may need to be upgraded to handle doing that.
FWIW, I would probably not override data and just do:
[Bindable("dataChange")]
bublic function get product():ProductVO
{
return data as ProductVO;
}
-Alex
On 12/9/16, 10:50 AM, "carlos.rov...@gmail.com on behalf of Carlos Rovira"
<carlos.rov...@gmail.com on behalf of carlos.rov...@codeoscopic.com> wrote:
>Hi Alex,
>
>I get to work as you said, but trying to make a bindable var to reduce
>verbosity like this:
>
><mdl:ListItemRenderer xmlns:fx="http://ns.adobe.com/mxml/2009";
> xmlns:js="library://ns.apache.org/flexjs/basic"
> xmlns:mdl="library://ns.apache.org/flexjs/mdl"
> xmlns="http://www.w3.org/1999/xhtml";>
>
> <fx:Script>
><![CDATA[
>import vos.ProductVO;
>
> [Bindable]
> public var product:ProductVO;
>
> [Bindable("dataChange")]
> override public function set data(value:Object):void
> {
> if (value != data)
> {
> super.data = value;
> product = data as ProductVO; // I tried as well with
>ProductVO(data)
> }
> }
>]]>
></fx:Script>
>
> <js:beads>
> <js:ItemRendererDataBinding />
> </js:beads>
>
> <js:Span text="{product.label}"/>
>
></mdl:ListItemRenderer>
>
>
>makes product.label doesn't output nothing, do you know what can be
>happen?
>
>Thanks
>
>
>
>2016-12-09 17:48 GMT+01:00 Alex Harui <aha...@adobe.com>:
>
>> Well, that is a legitimate warning, but is innocuous. I'm tempted to
>>try
>> to figure out how to tell Maven to accept these warnings, but I don't
>>know
>> how to do that. That's why the Ant builds work. Or get the compiler to
>> suppress the warning.
>>
>> The other answer is to switch to ValueObjects if you are just using
>>plain
>> Object. Then your binding expression would look like
>> "{MyValueObject(data).label}. MyValueObject would have to have the
>> appropriate [Bindable] metadata.
>>
>> -Alex
>>
>> On 12/9/16, 8:39 AM, "carlos.rov...@gmail.com on behalf of Carlos
>>Rovira"
>> <carlos.rov...@gmail.com on behalf of carlos.rov...@codeoscopic.com>
>> wrote:
>>
>> >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/MDLEx
>> >ample/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.
>>
>>
>
>
>--
>
>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.
