Hi Markus, Thanks for trying FlexJS.
At this point in time, FlexJS isn't trying to emulate the Flash Player's APIs. That could change if that's what folks really want, but IMO, it is better to try design a framework that will run optimally when cross-compiled. That's because I think there are some differences between the way Flash works and the browsers work, and we only have a small number of folks working on FlexJS right now so leveraging the browser's capabilities seems like the most efficient path and should give you the best performance in the end. Here's an example: Let's say we did try to emulate flash.display.Sprite. Would we also then need to emulate the flash.events.Event.ENTER_FRAME event? If so, would we then need to cache all changes to Sprite until an ENTER_FRAME event? Because that's how Flash works, while modifying a DOM object in the browser is immediate. If we didn't do that, code you currently have that expects that you can make lots of incremental changes to a Sprite before it gets rendered will have a very different interim visual result. There are other things like that as well. For example, I think having a working accessibility API is important so if we don't use DOM objects in the browser we'd have to write an entire accessibility implementation. But if we use DOM objects in the browser, there are limitations as to what kind of Flash-like things are easy to draw in those DOM objects, especially if you want to support old browser like IE8. So, right now, we are suggesting that you scan your code for "import flash" and use the results as a way to estimate how much porting work you will need to do. Then you can decide whether to build a JS emulation of some of that flash stuff or whether it is better to port that code to FlexJS APIs. Even if we did auto-translate "import flash" to "import org.apache.flex.*" you'd still get a lot of compile errors because many APIs would be missing from the FlexJS versions. While you may not be able to use low-level Flash APIs in FlexJS, it was even a goal in the current Flex SDK to hide a lot of those Flash APIs anyway. SystemManager wraps the root, for example. With FlexJS, you have to work from the higher-level component APIs, many of which should look and feel much like Flex components. And, finally, all of this is just my current opinion, and I'm more than willing to discuss whether this is the right direction or not. -Alex On 1/30/14 3:16 AM, "Markus Gritsch" <markus_grit...@gmx.de> wrote: >Hi group, > >Spending some time in converting an existing flex project to JS I have a >question about Class wrapping around flash packages like >org.apache.flex.events.Event. If my understanding is correct I have to >change all package declaration in my as3 code to org.apache.flex.x.x. A >cool think would be if the compiler could check the base class every time >a flash package declaration is found and replace the flash class >flash.events.Event with the corresponding Wrapper - >org.apache.flex.events.Event - at compile time - not in the code itself. > >Did I miss something? > >Thanks, > >Markus
