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 Wed, 27 Jul 2016 19:20:00 GMT
Yes. It was a significant change. You can see what I did on the “refactor-sprite” branch.

I spent the whole day on this. I just committed the last change to make all the projects compile
with no errors. (I did not test the examples.)

I changed 4 base classes: HTMLElementWrapper, CSSShape, ButtonBase and CSSTextField (I also
made CSSSprite bas off HTMLElement.) These each wrap Sprite, Shape, SimpleButton and TextField

They proxy the setters and getters to the composed objects where appropriate. CSSTextField
in particular, I proxied a lot of the functionality because it’s only used by Flash anyway.
The underlying Flash objects are available using sprite, shape, button and textField.

The only class which still subclasses Sprite is Application. I don’t know a way around that.

The big question here is how to handle events. We could attach event listeners for every conceivable
event and forward the events out. I’d like to avoid that if possible. I’m wondering if
there’s a way to override addEventListener and removeEventListener so we’d only attach
event listeners when we know someone is listening for them.


On Jul 27, 2016, at 8:42 PM, Alex Harui <aharui@adobe.com> wrote:

> On 7/27/16, 1:14 AM, "Harbs" <harbs.lists@gmail.com> wrote:
>> I’m running into lots of issues with the fact that HTMLElementWrapper
>> extends Sprite. The underlying problem is because all the native Flash
>> properties and methods are being exposed to the compiler for all
>> sub-classed objects.
>> For my port this is causing two issues:
>> 1. It’s hard to find all the dependancies on Flash. Ideally, I’d like to
>> base my components off FlexJS ones instead of Spark and native Flash ones
>> and have the compiler find the pieces I’m missing. This is not working
>> because a lot of pieces appear to the compiler as fine because Sprite is
>> the base class.
>> 2. I’m getting lots of conflicts with property and method names. This is
>> mostly happening with components which were based off of Spark, but I’m
>> getting lots of compiler errors where pieces are not marked as overrides.
>> They should not have to be marked as overrides because FlexJS does not
>> implement them, but Flash does.
>> The third issue is related to code completion help. The user should not
>> get hints for Flash properties and methods because they will not work in
>> HTML.
>> It seems to me that HTMLElementWrapper needs to be changed to compose a
>> Flash Sprite and proxy drawing and properties to that, but not actually
>> expose it any more than the underlying HTML element is being exposed. It
>> probably makes sense to have an element property on Flash as well which
>> is a Sprite.
>> Any clues on how much work this will be?
> Sounds like a significant change, but feel free to try it in a branch.  It
> might in fact be the right thing to do.  I think there may be a lot of
> assumptions about components parenting components and event flow through
> the DOM that would need to be changed.
> Regarding code-hinting, it should be as simple as adding [Exclude]
> metadata to block all the Flash things we don't want.
> -Alex

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message