flex-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Carlos Rovira <carlos.rov...@codeoscopic.com>
Subject Re: [FlexJS] How Binding works?
Date Fri, 09 Dec 2016 20:05:56 GMT
Thanks Chris, I'm searching for config, but still don't know what file I
should look. Could you share a path and concrete file to look for? thanks

2016-12-09 20:56 GMT+01:00 Christofer Dutz <christofer.dutz@c-ware.de>:

> In general you could tweak the config-xml templates which are part of the
> flexjs-maven-plugin.
> After all probably the Ant version simply has different defaults here. I
> think they should be reported as warnings, but not break the build. (In
> that particular type of problem).
>
> Chris
>
>
>
> Am 09.12.16, 17:48 schrieb "Alex Harui" <aharui@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.rovira@gmail.com on behalf of Carlos
> Rovira"
>     <carlos.rovira@gmail.com on behalf of carlos.rovira@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 <aharui@adobe.com>:
>     >
>     >>
>     >>
>     >> On 12/9/16, 5:35 AM, "carlos.rovira@gmail.com on behalf of Carlos
>     >>Rovira"
>     >> <carlos.rovira@gmail.com on behalf of carlosrovira@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.

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message