On 7/28/16, 9:58 PM, "Harbs" <harbs.li...@gmail.com> wrote:
>I gave everything a $displayObject property which is an alias to the >specific DisplayObject type. There’s also $sprite $textField $shape and >$button for the specific types. > >I did this to avoid having to do casting all over the place. > >I did not use element because it was a IFlexJSElement and Flash doesn’t >know what to do with that. Maybe I'll revisit this after we see if we can get Application to not be a Sprite. In my thinking, we'd borrow the interfaces from regular Flex that contain all of the APIs for InteractiveObject and have IFlexJSElement extend that. I think we will want a consistent back-pointer from the Flash object to the wrapping instance. That's what flexjs_wrapper does in the JS side. We'd have to subclass the Flash classes to add a flexjs_wrapper property and use them instead of plain Sprite, SimpleButton, etc. Then we could use the "element" property and not have HTMLElementWrapper always instantiate a Sprite. Button would instantiate a SimpleButton. Doing that in createElement overrides would theoretically share more code with the JS side. Similarly the "positioner" property could be repurposed as well. Individual components could certainly have a separate property to save on casting, but it might just be a var instead of a getter to save on function call overhead of getters. I could be missing some advantage of doing it the way you did though. Meanwhile, I have Application refactored to use a Factory class. Now to see if I can get DataBindingExample off the ground. -Alex