Hi Luke, Comments in-line.
On 10/26/15, 7:33 AM, "LukeWilimitis" <l...@ntrs.com> wrote: >Thank you for the reply, Alex. > >>Do you mean the mx UI widgets like mx:TextInput? Can you provide a list >>of which mx classes you are currently using? > >The app I am tasked with converting essentially uses a large amount of >classes from mx.binding, mx.collections, and mx.controls. So yes, classes >like mx:TextInput, but also a wide range of other classes: the app is so >large that I'd say a majority of the MX library is used. > >Here is the workaround I've proposed: > >- Create an ActionScript library project that contains all of the mx >classes >from the mx library, and behaves just as the mx library does in the >original >FlexSDK This is the key piece. I’m not quite sure the details of what you are planning here, but if you just copy in existing .AS files from the flex-sdk, they will probably have dependencies on flash classes that don’t exist on the JS side, so I don’t think you’ll get usable output. I’ve pondered 3 options (there may be more) for creating a more backward-compatible component set. A) Write JS to emulate those flash classes. This seems like a lot of work and may have performance issues (emulations generally don’t perform as well as native features). FlexJS is really trying to encapsulate browser patterns and present them in a Flex-like manner. B) Port UIComponent onto the current FlexJS framework. UIComponent is 13,000 lines of code so I’d probably start by commenting most of it out and seeing what is truly needed for mx:Button and mx:TextInput. But if it works, lots of other code that relies on UIComponent may “just work”. The downside is that to be 100% compatible with Flex, you have to retain the API signatures of UIComponent which has a lot of dependencies on lots of other Flex classes so this may also be a lot of work, and the result may be a lot of JS required to start up and run your app. C) Subclass the FlexJS components and/or re-compose their beads to emulate “most” of mx:Button and mx:TextInput, etc. This is likely to be the most performant solution, but is also a lot of work because you have to go visit every component. But you would start with the most common APIs your app needs and work your way up. If you look at the ASDoc, you’ll see that Spark Button has over 120 properties and methods and events! I haven’t counted up mx:Button, but it probably has just as many. But I’ll bet you use just a handful of them. >- Include this ActionScript library project in the app's dependencies, so >that when I try to compile it with FlexJS, the missing MX class errors are >resolved because this ActionScript library has the definitions for all the >mx classes that were previously missing >- Because FlexJS essentially converts AS->JS, the code should convert and >produce some usable level of output > >Of course, MX tags in .mxml files will have to be dealt with, but am I off >track in thinking this is a possible workaround? I would choose C, although B may be worth a try as well. But yes, you would create an AS Library Project for the code. The mx tags in MXML files should work if you create the appropriate manifest for it. If you can contribute this library to Apache Flex, that would be best. Others can then help work on it as well. I’m hoping to get a release of FlexJS out soon, and then I am hoping to finish up the back-port of our JS files into AS, then split time working on a test app and trying to do something similar for Spark controls. -Alex
