flex-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alex Harui <aha...@adobe.com>
Subject Re: [FlexJS] HTMLElementWrapper extending Sprite
Date Tue, 02 Aug 2016 19:40:49 GMT
I forgot to mention: the only casualty of the refactor so far was
TextItemRenderer.  It was designed to be a default renderer on the Flash
side and directly inject a TextField as the item renderer for things like
DataGrid.  Because a TextField's parent is DisplayObjectContainer but
components are expecting the parent to be IParent, we can no longer have
TextItemRenderer as an option.  No example seemed to care at this point,
so I opted to comment it out and worry about it later if we hear that the
SWF-side DataGrid is too slow.  Switching to unwrapped TextFields was an
important improvement in the MX DataGrid many years ago.  If we need it,
we might wire up some way of doing it.  The MX/Spark port might need it.


On 8/2/16, 12:33 PM, "Alex Harui" <aharui@adobe.com> wrote:

>On 7/30/16, 11:05 PM, "Alex Harui" <aharui@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
>>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
>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
>-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,

View raw message