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: <D3BE5BFF.719D9%aharui@adobe.com>
Date: Wed, 27 Jul 2016 23:27:01 +0300
Content-Transfer-Encoding: quoted-printable
Message-Id: <247BE937-7474-4ED9-825E-8CFE2CF2282E@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>
To: dev@flex.apache.org
archived-at: Wed, 27 Jul 2016 20:27:28 -0000


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

>=20
>=20
> On 7/27/16, 12:20 PM, "Harbs" <harbs.lists@gmail.com> wrote:
>=20
>> Yes. It was a significant change. You can see what I did on the
>> =93refactor-sprite=94 branch.
>>=20
>> 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.)
>>=20
>> 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.
>=20
> 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=85

>=20
>> They proxy the setters and getters to the composed objects where
>> appropriate. CSSTextField in particular, I proxied a lot of the
>> functionality because it=92s only used by Flash anyway. The =
underlying
>> Flash objects are available using sprite, shape, button and =
textField.
>>=20
>> The only class which still subclasses Sprite is Application. I don=92t =
know
>> a way around that.
>=20
> 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=92m not sure how bad it is for the =
main app to subclass Sprite. I=92ll leave this for someone else.

>>=20
>> The big question here is how to handle events. We could attach event
>> listeners for every conceivable event and forward the events out. I=92d=

>> like to avoid that if possible. I=92m wondering if there=92s a way to
>> override addEventListener and removeEventListener so we=92d only =
attach
>> event listeners when we know someone is listening for them.
>=20
> 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=92m not =
exactly sure what it=92s 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=92m not sure how many are going to be needed, but potentially =
a lot. Here=92s the idea that I=92m thinking of:

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

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