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 20:27:01 GMT

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

> On 7/27/16, 12:20 PM, "Harbs" <harbs.lists@gmail.com> wrote:
>> 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 respectively.
> I haven't looked at the code yet, but congrats for being able to do it in
> a day!

:-) Sublime Text was very helpful in making the edits with its multi-slect feature…

>> 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.
> One idea is that, since developer code never instantiates an Application
> (only the framework does) that Application could be an interface.  The
> framework would instantiate the concrete class.

Not sure how to go about this, but I’m not sure how bad it is for the main app to subclass
Sprite. I’ll leave this for someone else.

>> 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.
> Doesn't the JS side already have a solution for this?  addEventListener on
> the wrapper calls addEventListener on the wrapped element for certain
> events.

Not sure. There is some goog-specific event proxying, but I’m not exactly sure what it’s
doing. I guess we could add specific events as needed, but I think it would be really great
if it could happen automagically. How much overhead is there by adding a whole list of event
listeners for every object created? TextField has 78 possible events. I’m not sure how many
are going to be needed, but potentially a lot. Here’s the idea that I’m thinking of:

 override public function addEventListener(type:String, handler:Function, opt_capture:Boolean
= false, opt_handlerScope:Object = null):void
        	super.addEventListener(type, handler, opt_capture, opt_handlerScope);

        	// create a function which would field the event fired from Flash 
        	// it would examine the event to know what kind of event it needs to throw
        	// It might have a reference to “handler”, but it might not need to because it’s
already listening
        	sprite.addEventListener(type, proxyHandler, opt_capture);

View raw message