Mailing-List: contact dev-help@flex.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@flex.apache.org
Content-Type: text/plain; charset=windows-1252
Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\))
Subject: Re: [FlexJS] HTMLElementWrapper extending Sprite
From: Harbs <harbs.lists@gmail.com>
In-Reply-To: <D3C0DEA4.71BEB%aharui@adobe.com>
Date: Sat, 30 Jul 2016 22:13:58 +0300
Content-Transfer-Encoding: quoted-printable
Message-Id: <A9D410BF-3BB0-4815-8FBE-22417756BF7E@gmail.com>
References: <57064EB8-471B-4628-B7BF-F27B79D0854E@gmail.com> <D3BE3F22.71955%aharui@adobe.com> <AC0009BB-AE55-4AFE-B2D3-B600035FF15B@gmail.com> <D3BE5BFF.719D9%aharui@adobe.com> <247BE937-7474-4ED9-825E-8CFE2CF2282E@gmail.com> <D3BE69DC.719E7%aharui@adobe.com> <D3BF9FDA.71B0C%aharui@adobe.com> <D3BFBDC3.71B2E%aharui@adobe.com> <5A405A94-DB41-44C4-B52B-323A384F7018@gmail.com> <D3BFD8C3.71B4D%aharui@adobe.com> <96B04748-F78C-42D8-B4C6-CF5D5BE540E9@gmail.com> <D3C0363A.71B75%aharui@adobe.com> <F1C64652-898B-4D8C-A226-B7E1FA16FF2A@gmail.com> <F6DC7F63-0B22-4BEA-9433-CF8D226203A2@gmail.com> <D3C0448E.71B93%aharui@adobe.com> <BD0BE2A7-B874-4867-AEC8-83A7FB53BFC4@gmail.com> <D3C0DEA4.71BEB%aharui@adobe.com>
To: dev@flex.apache.org
archived-at: Sat, 30 Jul 2016 19:14:09 -0000

Combining multiple responses:

>> Okay. I just implemented WrappedShape, WrappedSimpleButton, =
WrappedSprite
>> and WrappedTextField. I hope that helps you.
>>=20
>> I did not implement a createElement method because I did not see the
>> point. On the HTML side there=92s code that=92s specific to a lot of
>> different individual elements, but on the Flash side it=92s really =
simple.
>=20
> 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 =3D upSprite.$sprite;
instead of this:
(b.$displayObject as SimpleButton).upState =3D upSprite.$displayObject;

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

Here=92s 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=92d 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. But:

First of all, CSSTextField is not a SWF-only class. I=92m not sure if =
it=92s used anywhere in JS, but I assume it could. It=92s 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 objects.

The only thing I=92m 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=92m also not clear on why to have both UIElementWrapper and =
FlexJSElementWrapper. Why would you not always want the strand =
implementation?

Harbs=