@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/