Notes on Extending FlexBuilder (Part 1: Metadata Processing)

For the last couple of weeks I've been hard at work mucking with FlexBuilder internals. I'm building an Eclipse/FB plugin to provide features in support of an upcoming framework. So far the results have been positive but there have been a few gotchas.

Much of the work has been on metadata (i.e. annotations in the Java world) processing. Java has extensive annotation processing support but not so much with Flex. There is some promising stuff on generic compiler extensions in Flex4 but ultimately I entered a new bug to ask for real IDE support. If/when Adobe gets around to this it will be great, but in the meantime I've gone ahead and forged my own route. The Eclipse plugin is essentially a new Eclpse project builder that uses the readily available FlexBuilder code model API. Initial results are good:



As you can see, the plugin can identify metadata tags and provide validation and error markers. But there have been a few gotchas. Of course, things tend to crop up when you're using an API in a new unexpected way. First issue: the documented public API doesn't provide a way to get the full list of tag attributes on metadata tag. If you know the attribute name you can call IMetaTag#getValue(name) but if you don't know what the potential attributes are you'll need to cast down to an internal type. If you cast IMetaTag to BasicMetaTagNode you'll find getAdaptableChildren() which will return you an array of the attributes.

The second issue is similar. There's no public documented way to determine from an IMetaTag where in the .as or .mxml file it came from. This is critical to allow us to put error markers associated with the correct line numbers. Fortunately if we cast down again to BasicMetaTagNode we can call getStart() and getEnd() to return the file offsets. Still that only works when the metadata tag includes attributes (i.e. [MyMetadata(attribute="value")] ). When you include a metadata tag with no attributes (i.e. [MyMetadata] ) the code model doesn't seem to store the start and end values (they're always -1). This is probably the most annoying problem. As a workaround the plugin will drop down to the tag's associated node and show the problem there. This doesn't look great but at least the user sees an error.



Notice how the error icon and the red squigglies are associated with the class and not the metatag itself :(

The final issue seems like a straight-forward bug. The FB code model throws an ArrayStoreException when you try to retrieve metadata associated with a getter/setter function (see bug). This has meant the plugin can't parse any metadata associated with accessor functions. Thats unfortunate and hopefully Adobe will fix this one (go vote on it!).