I haven't given up on my VanillaSDK idea, but as I don't even have time to help finish FlexJS now, it'll be a while before I get to work on that again ;-)
EdB On Thu, Jan 30, 2014 at 7:06 PM, Alex Harui <aha...@adobe.com> wrote: > 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 > > -- Ix Multimedia Software Jan Luykenstraat 27 3521 VB Utrecht T. 06-51952295 I. www.ixsoftware.nl
