Potomac - OSGi-inspired Flex framework

Monday, August 24, 2009 14 comments
Before I post my next 'Extending FlexBuilder' post, I figure I should talk about why I'm doing such a thing. Truth is, I'm working on a Flex framework. Cue the collective groans from the Flex community. Do we really need another framework? .. Well this framework is a bit different. The primary focus is on modularity. Specifically, the Potomac framework (the name we're using) will be an OSGi-inspired modular UI composition platform. For the last few years I've been working in the Eclipse Rich Client Platform (RCP). Essentially, Potomac takes the principles and goals of OSGi and the Eclipse RCP and brings them to Flex.

Why not just use the normal Flex module system? A couple of reason. First, the IDE support for Flex modules is very simplistic. Modules are defined inside application projects. This makes large, enterprise-level development difficult. When you have multiple teams working together to produce one large application, you want each team to be working on their pieces in their own projects. Also, having the modules inside the application project prevents them from being reusable in other projects. Once we start thinking about modules being reusable, we can quickly count off many reasons why the current module system is lacking. Thats not to say we should throw it away. In fact, Potomac 'bundles' are built and delivered as Flex modules (just with a lot of stuff thrown in).

Potomac will be:
  • New module system for Flex including new FlexBuilder 'bundle' support
  • Extension mechanism inspired by, but quite different than, Eclipse extension points
  • UI Composition and templating framework

Stay Tuned. We'll be releasing Potomac in a few weeks.

Notes on Extending FlexBuilder (Part 1: Metadata Processing)

Thursday, August 13, 2009 0 comments
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!).