Flex Pasta » 2009 » January
Have you used modules for your Flex applications? If you haven’t, modules are simply a way to split your application into pieces. Rather than having one giant SWF file based on an mx:Application tag, you have multiple “module” SWF files which are loaded at runtime by the main SWF application. The modules know at compile time which classes the master application SWF file will have, thus reducing the amount of compiling needed on the child module SWF files. This makes Flex with modules a great way to reduce compile times. I would like to see improvements in Flex Builder and the Flex SDK to support easier modularized Flex development. Modules are a critical piece to the enterprise Flex landscape. Anyone creating a large application with Flex has probably seen lengthy compile times when using a single mx:Application tag(so modules are important!!!). Here are my top 5 improvements for Flex 4 and modules.
5. Create a new Flex Modules “View” window in Flex Builder
It would be great to have a tree view window showing the modules being built in a project. Let’s have a window that shows the modules name, time last built, module size, compile time length, and a tree view of all the classes included in the module. If a developer makes a coding mistake, or even leaves an unused import in the wrong module, it can result in a module with a bloated number of classes that it doesn’t need. It is very hard to track down this problem once it has happened, and it is too time consuming to keep up with. The whole point of modules is to reduce compile and run times. Developers need the tools to support modules.
4. Better documentation and example applications with modules
Modules are a complicated topic, especially when you throw in things like Cairngorm, Penne, Mate, or whatever other framework you might be using. Therefore, it would be nice to see some examples of real applications using modules sucessfully.
3. When Flex Builder does a compile, show the output of the compiler arguments for ant and maven.
When Flex Builder makes a call to mxmlc, there are certainly arguments passed in just like when running a command line build with mxmlc. When doing a deployment, either through ant or maven, figuring out the command line arguments for the build can be quite tricky. And that is just when building one Flex application. When doing an ant or maven compile with modules, the problems are compounded. To do a command line compile with modules, first you must build the main application file, outputting a link report xml file. The linking file then must be a parameter for the build of each module, letting the compiler know that the main application file already has some of the classes it needs. Coming up with the syntax for all of this takes at bit of googling to say the least. I think it would be fairly simple feature request for Flex Builder to dump the compiler arguments to the console.
2. Make Flex and modules work like Java class files
If I have 50 Java class files and I modify one, only the .class file for that Java class is recompiled and deployed to my local server. It makes it quick to test and keep right on developing. I would like to see a feature that has the Flex compiler compile each as/mxml file individually and then deploy it to a local server. The SWF file would load each as/mxml file on an as need basis. By compiling on a file by file basis, it would all but eliminate compile times. I realize that this feature might be difficult to add. It may even be impossible since the SWF file could potentially be loading hundreds of classes at a time. I’m not advocating deploying an application like this to a user base, you would use an RSL for this. What I am suggesting is for development purposes. To reduce compile times and make developers lives easier.
1. Fix all the compiler/Flex Builder bugs related to modules
Certainly the Flex team has put in a lot of time and effort into modules, and they have done a good job with the Flex modules platform. But please don’t stop investing in the development of module support. There are a good number of bugs with modules. You will see morbid errors at runtime that even a clean doesn’t fix. For example:
VerifyError: Error #1014: Class mx.containers::HDividedBox could not be found.
at flash.display::MovieClip/nextFrame()
at mx.core::FlexModuleFactory/deferredNextFrame()[C:\Adobe\source\sdk\branches\3.x\frameworks\projects\framework\src\mx\core\FlexModuleFactory.as:467]
at mx.core::FlexModuleFactory/update()[C:\Adobe\source\sdk\branches\3.x\frameworks\projects\framework\src\mx\core\FlexModuleFactory.as:295]
at mx.core::FlexModuleFactory/moduleCompleteHandler()[C:\Adobe\source\sdk\branches\3.x\frameworks\projects\framework\src\mx\core\FlexModuleFactory.as:542]
at flash.display::MovieClip/nextFrame()
at mx.core::FlexModuleFactory/deferredNextFrame()[C:\Adobe\source\sdk\branches\3.x\frameworks\projects\framework\src\mx\core\FlexModuleFactory.as:467]
at mx.core::FlexModuleFactory/update()[C:\Adobe\source\sdk\branches\3.x\frameworks\projects\framework\src\mx\core\FlexModuleFactory.as:295]
at mx.core::FlexModuleFactory/moduleCompleteHandler()[C:\Adobe\source\sdk\branches\3.x\frameworks\projects\framework\src\mx\core\FlexModuleFactory.as:542]
at flash.display::MovieClip/nextFrame()
at mx.core::FlexModuleFactory/deferredNextFrame()[C:\Adobe\source\sdk\branches\3.x\frameworks\projects\framework\src\mx\core\FlexModuleFactory.as:467]
at mx.core::FlexModuleFactory/update()[C:\Adobe\source\sdk\branches\3.x\frameworks\projects\framework\src\mx\core\FlexModuleFactory.as:295]
at mx.core::FlexModuleFactory/moduleCompleteHandler()[C:\Adobe\source\sdk\branches\3.x\frameworks\projects\framework\src\mx\core\FlexModuleFactory.as:542]
There are compile errors that don’t show up in the Flex problems window. Charts can randomly turn black in a module. Embedded fonts are nearly imposible to use. And if you would like to really bang your head against a wall, try refactoring code used across multiple modules(try it out if you don’t believe me). Please help Flex developers out by knocking out some of these bugs.