On 7/27/16, 12:20 PM, "Harbs" <harbs.li...@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! > >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. > >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. -Alex
