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 Sun, 31 Jul 2016 06:05:58 GMT

On 7/30/16, 12:13 PM, "Harbs" <harbs.lists@gmail.com> wrote:

>> In order to get Application to wrap the root, I will have to do more
>> mucking in this area.  I may add createElement because it lets us
>> what gets created as the wrapped element is a more common way.
>> if a subclass wants to create a different element, the superclass will
>> have unnecessarily created a different element.
>I’d like to see a use case before we do this. It seems like it should be
>pretty clear which subclasses to start from in Flash (as is currently
>being assumed with the sub-classing).

It would be nice if Application could extend HTMLElementWrapper since we
want it to wrap the root in the SWF or Body in JS.  Since we don't want
HTMLElementWrapper to extend Sprite, we need to use a FactoryClass in
order to bootstrap the SWF with a MovieClip (two-frame SWF like regular
Flex).  And so having HTMLElementWrapper's constructor generate a Sprite
is not useful for Application.  By calling createElement, Application can
override createElement and create something else (actually, for
Application, it won't create anything as the root MovieClip has already
been created and is assigned to the Application by the Factory).

>> Related thought, so I don't forget: It isn't clear that CSSShape and
>> CSSTextField which are only used in SWF implementations needed to become
>> HTMLElementWrappers.
>I was wondering about that myself. When I started, I did not notice that
>they seem to be SWF-only. But:
>First of all, CSSTextField is not a SWF-only class. I’m not sure if it’s
>used anywhere in JS, but I assume it could. It’s also possible that
>CSSShape can get a JS implementation as well. I might actually use it for
>the svg primitives. (not sure yet)
>Even if not, it seems like it makes sense to keep the same pattern.

I'm worried that we'll be sorry if we add additional function call
overhead to the leaves of the display object tree.  For example, every
time we access x,y,width,height it will result in extra function calls
through the wrapper.

A TextField emulation exists for the MX/Spark port where we don't care
about overhead.  I would be cautious about replicating all of TextField to
the JS side to do text for the graphics SWC.  There are some funky APIs
around textColor vs TextFormat.  IMO, we want to have low overhead on the
JS-side and emulate SVG on the SWF side.

>> So now, I'm pondering a couple of deeper refactors.  One is something
>> -create a ElementWrapper class.  It has an element property.
>> -create a UIElementWrapper class.  It subclasses WrappedElement and adds
>> parent, x, y, width, height, visible, alpha that proxy to the element.
>> -rename HTMLElementWrapper to FlexJSElementWrapper.  It would add the
>> strand implementation.
>> -CSSShape and friends subclass UIElementWrapper
>> -HTTPService subclasses ElementWrapper
>> -UIBase and Application subclass FlexJSElementWrapper
>I assume the ElementWrapper has the Bead related code that HTTPService
>seems to be implementing on the SWF side.
>I like this option. It seems clean and makes sense to me.
>UIElementWrapper would have element for cross-platform use.
>UIElementWrapper would have $displayObject for Flash-only use.
>CSSSprite and friends would have the $sprite and friends for easy typed
>access to the Flash objects.
>The only thing I’m not clear on is where the Flesh objects get
>instantiated. I guess that could be in the UIBase constructor, or in a
>createElement function (if necessary).
>I’m also not clear on why to have both UIElementWrapper and
>FlexJSElementWrapper. Why would you not always want the strand

Because the low-level CSSShape and friends probably won't need beads hung
on them.  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.


View raw message