Flex Monkey Patches

A useful compiler switch to help with this is the -dump-config switch.

If you add -dump-config=c:\mycfg.xml to the compiler, it will generate a config file that represents all the compiler (either for mxmlc or compc) settings used for compilation in a Flex Builder compile and then you can use that config file in a commandline compile to do an equivalent compile.

A few notes on the generated configfile.

1. The file is not perfect. I found that the tag that was generated only had a relative path generated. It is much better if that were absolute, so before I used the config file, I changed the value for that tag to something like:

2. For some reason the generated file has a token ${flexlib} which didn’t get resolved and filled in. I found that I could just comment out the 2 properties in the config file as they aren’t relevant to most compilations.

3. I found the easiest way to use mxmlc/compc was to copy the generated config file to the bin dir of the SDK under Flex Builder install. Then I could invoke mxmlc against the app like so:

./mxmlc -load-config+=mycfg.xml C:/myapp/src/app.mxml -output myswf.swf

4. For compc, the classes to actually compile to include in the generated swc aren’t actually output to the generated config file, so you have to add them manually (or on the commandline). I found the easiest way to do this was to add tags like below in the generated configfile

The content for those tags comes from the project file - .flexLibProperties which looks something like this:

The classEntry paths translate into the class tag values.
After doing this you can run compc like this:

./compc -load-config+=mycfg.xml -output myswc.swc

HTH

-Kyle

I had seen references describing how to do this, but hadn’t seen a complete example, so I whipped this one up for a customer.

Using RemoteClass metadata triggers code gen in in the compilter to ensure that the class is registered with the VM before the application can use it, this includes receiving it from a network request. The only case in which this could be a problem is if it was being used with remoting and there wasn’t a corresponding server class that also implemented the flash.utils.IExternalizable interface.

Externalizable interface doesn’t effect the ability to be serialized in AS3, it just provides customization of what gets serialized. Generally it is only used to serialize private data or hide public data from serialization. Marking the class with [RemoteClass] is what allows the typed serialization of the object (again just mxmlc code gen at the right point using the registerClassAlias() method).

There aren’t any issues, at least none that we have hit, with LSO storage and custom serialization using IExternalizable. As long as the SWF that is retrieving the data from the LSO has the IExternalizable classes linked in and registered (potentially with a “dummy variable”) then I don’t know of any reason why that wouldn’t work.

The real work behind the scenes is done by using flash.net.registerClassAlias() and it is documented (although hard to find) at:
http://livedocs.adobe.com/flex/201/html/lsos_087_3.html

Browse the source of this example.
Download a zipfile containing the source to this sample.

Read the rest of this post»