@Greg Dove <greg.d...@gmail.com> , would you be able to take a look at the
help docs about data binding [1] and either make or suggest appropriate
improvements?

Thanks in advance!

a

[1] https://apache.github.io/royale-docs/features/data-binding


On Fri, May 22, 2020 at 8:08 AM Greg Dove <greg.d...@gmail.com> wrote:

> Sorry there was an unfinished sentence above:
>
> The Royale bindings implementation does not run
>
> was supposed to be
> The Royale bindings implementation does not run in exactly the same way as
> Flex, and this remains true after the changes. So legacy code that depends
> on the order of execution of Flex bindings probably won't magically start
> working with this. But it at least means that all the bindings from the
> original code should be possible to run.
>
>
>
>
>
>
>
> On Fri, May 22, 2020 at 11:02 PM Greg Dove <greg.d...@gmail.com> wrote:
>
> >
> > Just an explanation of various binding improvements that have been added.
> > (I'm waiting for one of the builds to complete, but it has worked
> > locally for a week in copious testing.)
> >
> > The major change is a fix to something that has never worked : mxml
> > binding 'inheritance'.
> > This is usually where the class ancestry chain cycles in and out of mxml
> > and actionscript - and is a relatively common pattern in legacy code.
> > The implementation does what you would expect - ancestor bindings are
> > run before subclass bindings.
> > The Royale bindings implementation does not run
> > There are also fixes for conflicting names for generated event handlers
> > (js) and generated ids (swf and js). This was happen with mxml ancestors.
> >
> > I have fixed the above and tested in both swf and js. Code that doesn't
> > need the fix continues to work as before. Binding unit tests continue to
> > pass as before.
> >
> > SDK Bindings code has a tidy up and should now be lighter weight for most
> > cases because of reduced duplication. More tweaking here might see the
> > possibility to reduce it further using @royalesuppressexport but that can
> > come later. Functionality first...
> >
> > I also needed to address some other binding issues, so I think Piotr will
> > be pleased that I finally fixed a bug he logged last year (sorry it took
> so
> > long). And I know Harbs has mentioned issues with the use private
> bindings.
> > I fixed the getter/setter usage for private bindings (and matched how
> Flex
> > does it - it simply uses the plain name for the propertyName in the
> event,
> > in the same way it would if it were public). These were previously
> > dispatching the long 'private' property name from the setters but
> watchers
> > were listening for the plain (short) name. That is fixed now.
> >
> > All changes were implemented and tested for swf as well as js. Swf is
> > generally a little trickier to work on for this stuff, but in this case
> it
> > was relatively straightforward (the function bindings work I did a few
> > months back was more challenging).
> >
> >
> >
>


-- 
Andrew Wetmore

http://cottage14.blogspot.com/

Reply via email to