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
 

Reply via email to