If it works (and has better performance), I’m OK with leaving the CSS family of objects as subclasses of the Flash ones. It looks like you left UIButtonBase as a wrapper rather than a subclass of SimpleButton. Is that an oversight, or was it done purposely?
I’ll let you know if this approach brings up other issues, but I’m not coming up with problems at first glance. Tomorrow I have a long list of non-FlexJS issues I need to deal with, so I’m probably not going to pick this up again until Thursday. Harbs On Aug 2, 2016, at 10:33 PM, Alex Harui <aha...@adobe.com> wrote: > > > On 7/30/16, 11:05 PM, "Alex Harui" <aha...@adobe.com> wrote: >> I will probably try to code up the other option and see where >> the pain points are. There might be some killer issue. I'd like to avoid >> wrapping the CSSShape and friends. > > Well, I just pushed to the refactor-sprite branch changes to get > DataBindingExample to show up (but doesn't respond to events) with > -Application also wrapping a display object instead of extending Sprite > -CSSShape and friends are subclasses instead of wrappers > -UIHTMLElementWrapper extending HTMLElementWrapper as the base for all UI > widgets. > > IIRC, the main goal was to make sure there weren't all of those Flash APIs > that don't have JS equivalents exposed in the API surface in the > documentation and code intelligence in the IDEs. Hopefully these changes > will accomplish that without sacrificing performance at the leaves of the > tree of display objects. > It helps us in other ways as well in that the parent property is no longer > a DisplayObjectContainer like it used to be on the SWF side. And I think > that and other changes open the door for a lot more shared code between > the JS and SWF side. > > First I want to see if Harbs is ok with these changes in that it hides the > Flash APIs that were bugging him, then I might do a bit more refactoring > because I now don't like some of these class names. Right now > UIHTMLElementWrapper is the base for all widgets. There is still a > UIButtonBase that extends UIHTMLElementWrapper, and UIBase also extends > UIHTMLElementWrapper. What I think we should do is: > -rename HTMLElementWrapper to ElementWrapper > -rename UIHTMLElementWrapper to UIElementWrapper (Application will extend > UIElementWrapper) > -create a new UIBase that extends UIElementWrapper and implements IUIBase > (x,y,w,h,alpha,visible will move here from UIHTMLElementWrapper) > -rename UIButtonBase to ButtonBase > -rename the current UIBase to ComplexUIBase > > The current UIBase assumes that children can be added to the component, > which isn't always the case, and on the SWF side, Buttons were not UIBase > (which was a good test of forcing us to use IUIBase instead of UIBase > more. But with these additional changes, we can have a base class on the > SWF side for every component as well. > > Finishing this refactor could be a lot of work because of casting. There > are lots of places I've found already where the Strand is assumed to be a > DisplayObject. The compiler does not find these, you can only find them > by searching or at runtime. > > Anyway, I'm off to try to get the event system working. > > Opinions and questions welcome, > -Alex >
