On 7/27/16, 1:14 AM, "Harbs" <harbs.li...@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
