flex-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Harbs <harbs.li...@gmail.com>
Subject Re: [FlexJS] HTMLElementWrapper extending Sprite
Date Sat, 30 Jul 2016 19:13:58 GMT
Combining multiple responses:

>> Okay. I just implemented WrappedShape, WrappedSimpleButton, WrappedSprite
>> and WrappedTextField. I hope that helps you.
>> I did not implement a createElement method because I did not see the
>> point. On the HTML side there’s code that’s specific to a lot of
>> different individual elements, but on the Flash side it’s really simple.
> Well, on the SWF side there is current CSSShape, UIBase, UIButtonBase,
> StyleableCSSTextField, maybe others.  With this change, these four classes
> can theoretically be collapsed into one (UIBase) where createElement
> creates the Shape, Sprite, Button, TextField, whatever.  Then the
> lifecycle would be much more similar to the JS-side (or so I think).

True. But having separate classes makes accessing the underlying typed DisplayObject much
easier and clearer.
You could do this:
b.$button.upState = upSprite.$sprite;
instead of this:
(b.$displayObject as SimpleButton).upState = upSprite.$displayObject;

The number of possible base UI classes is pretty limited on the SWF side, so I like this way

Here’s the full list of potential additional objects as I see it:
Bitmap, Video, Loader, TextLine

> 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 control
> what gets created as the wrapped element is a more common way.  Otherwise
> 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).

> 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.

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.

> So now, I'm pondering a couple of deeper refactors.  One is something like:
> -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

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 implementation?

View raw message