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?

Thoughts?

Harbs

Reply via email to