Binding improvements

[Greg Dove <gr...@gmail.com>]

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

[Alex Harui <ah...@adobe.com.INVALID>]

Sound great!  Thanks.

-Alex

On 5/22/20, 4:08 AM, "Greg Dove" <gr...@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 <gr...@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).
    >
    >
    >
    

Re: Binding improvements

[Andrew Wetmore <co...@gmail.com>]

@Greg Dove <gr...@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 <gr...@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 <gr...@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/

Re: Binding improvements

[Greg Dove <gr...@gmail.com>]

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 <gr...@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).
>
>
>