Re: Binding improvements
@Greg Dove , 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 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 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/
Re: Binding improvements
Sound great! Thanks. -Alex On 5/22/20, 4:08 AM, "Greg Dove" 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 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). > > >
Re: Binding improvements
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 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). > > >