The configs are the same regarding warnings. The warnings are output in
both Ant and Maven. Let's use the other thread to try to work through
this.
-Alex
On 12/9/16, 12:55 PM, "Christofer Dutz" <christofer.d...@c-ware.de> wrote:
>Hi Carlos,
>
>they are all in:
>flexjs-compiler/flexjs-maven-plugin/src/main/resources/config
>
>Depending on the type of compilation different templates are used.
>
>Chris
>
>
>Am 09.12.16, 21:05 schrieb "carlos.rov...@gmail.com im Auftrag von Carlos
>Rovira" <carlos.rov...@gmail.com im Auftrag von
>carlos.rov...@codeoscopic.com>:
>
> 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.d...@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" <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.
>
>
