On 1/18/16, 8:40 AM, "OK" <[email protected]> wrote:
>>But if you want to see the SWCs functionality work without Flash, you >>actually need to cross-compile the source code for the SWC with the >>FlexJS/FalconJX compiler. > >By doing this with the PureMVC lib I've got a "File not found" error while >cross compiling my FlexJS project >(see log at the end), do you've any idea what I've done wrong?: > >These are the steps that I've done using FlashBuilder 4.7: >- Create a new Flex library project >- Select "FlexJS 0.6.0 SDK" as "Flex library compiler" >- Paste the PureMVC source code into the library project >- Copy the auto created swc to the "lib" folder of my FlexJS project >- Compile my FlexJS project by using "External tools" -> 1 FlexJS (Falcon >JX...) > Ah yes, that made me realize that we haven't implemented auto-packaging of the JS files in the SWC. We are currently doing that via Ant script. So for now, there are some additional steps. After making sure the PureMVC code compiled to be a SWC without any errors in the Problems tab, the next step is to try to cross-compile it into a set of JS files. Try running "External tools" -> "FlexJS CompC". That will expose any Flash dependencies in the PureMVC code. It will probably also expose any dependencies on the regular Flex SDK which might have dependencies on Flash. But if that does compile without errors, then it should output a pile of JS files, one for each AS file. If you get errors, you will have to figure out what modifications to make to PureMVC to get rid of those errors. Feel free to ask here. I'm doing a similar exercise with the Spark and MX SWCs right now. Then, once the cross-compile is free of errors, you can either create an Ant script like we have for the FlexJS swcs to package the JS files into the SWC, or try telling FB to include those files, or, instead of using "External tools" -> FlexJS (FalconJX...) to compile the app, make a copy of that external tool and add an additional -sdk-js-lib= parameter pointing to the folder of JS files. > >>I'll ponder whether it will be practical to create a component set that >>lets you see some small portion of your UI written in FlexJS work in your >>regular Flex app in Flash. >Don't waste to much time on this. >My understanding now is that it makes most sense to start with FlexJS from >scratch... and that's ok! Well, not from scratch. If you have existing code, you should be able to re-use all or most of your .AS files. For the MXML files, it was easier/faster for us to produce a new component set for MXML UI instead of using one based on Spark in order to have something to show, and having a lighter weight component set should give you better performance and download speeds. And other folks said their apps were old and wanted to upgrade their UI anyway. And for many, the big dollar value in migration is in the AS code, not the UI. So right now as I write this, you have to do a fair amount of changes to your MXML files, but if the Spark-like component set becomes a reasonable option, you'll have to do far fewer changes (but probably not zero changes). > >>I'm writing a more Spark-like component set for FlexJS now. >I'm not a designer, but for me a modern look and feel is very very >important. >Is my understanding right that even with a Spark-like component set there >will be nothing similar to "Component skinning"? So if styles are not >sufficient to change the look and feel of a component we have to create an >own component set? There are actually at least two approaches to doing a Spark-like component set. One is to subclass the current FlexJS components and give them the outer API surfaces of the Spark components. But you are right that this approach won't have an identical skinning model. What I'm investigating right now is having UIComponent subclass the FlexJS UIBase. If it is practical to do that, then a component set based on that will probably have the same Spark skinning model, but realize that the size and performance of that may be insufficient. We'll see. Having ported the FlexStore example to FlexJS, I would say each MXML file needed to be touched. FlexStore didn't really leverage Spark Skinning that much, but I had to visit nearly every line in the MXML file to rename tags and attributes. Not too difficult, but apparently more work than most folks want to do. The FlexJS tags and attributes have different names in order to better map to native HTML controls and APIs where possible. I expect that the Spark-like component set based on subclassing existing FlexJS components would mean you wouldn't have to touch as many lines in your MXML files, but the skin-related files might be an issue, and any code where you expected a regular SDK type like UIComponent might need tweaking as well. So, that's why I'm currently exploring trying to put UIComponent on top of UIBase. It should allow your skin files to work as is, but again, size and performance may be an issue. And I might hit some other roadblock. Right now, it looks like I'd need Harbs to finish up the E4X emulation otherwise you'd have to touch more of your code where you used DescribeType. And some other code will have to be touched in order to deal with the fact that currently is no event priority and weak references in the JS runtime (and maybe never will be). HTH, -Alex
