Cool. I’m not totally getting the use case of the IFlexJSElement, but there’s definitely nothing wrong with adding a wrapper class that extends a Flash type.
I’d think it should extend DisplayObject rather than InteractiveObject though. On Jul 29, 2016, at 8:34 AM, Alex Harui <aha...@adobe.com> wrote: > > > 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 > >
