Thursday, 14 June 2007

Flex/flash could learn from Java and Maven

Yesterday I told my colleague how much I loved the tight integration between flex components and XML.
Pretty much any UI flex component can use a xml document as a dataprovider and you can dynamically use attributes or nodes in your component.
That really brings your application up to speed in a hurry.

Just as I had declared my affection for the integration I ran into a bug best demonstrated by this small example:

<?xml version="1.0"?>
<mx:Application xmlns:mx="" initialize="init()">
import mx.controls.Alert;

private var work:String = "<tmps><tmp att=\"abc\"><dummy/></tmp></tmps>";
private var wontWork:String = "<tmps><tmp att=\"abc\" /></tmps>";

private function init() : void {
result.text = work;

private function clickHandler(event:ItemClickEvent):void {
if (event.label == "OK") {
result.text = work;
} else {
result.text = wontWork;

private function printResult(event:MouseEvent):void {
var list :XMLList = XML(result.text).tmp;[0]); // should print first element in the list - the tmp element
<mx:Panel title="Flex bug example" height="100%" width="100%">
<mx:ButtonBar itemClick="clickHandler(event);">
<mx:String>not OK</mx:String>
<mx:TextArea id="result" editable="false" height="100" width="100%"/>
<mx:Button id="evaluate" label="evaluate result" click="printResult(event)"/>
The compiled version:

I want to get the first element of my "tmps" xml document. Casting the string to a XML document and work on it as a XMLList prevents me from getting the first element in the XMLList as long as the element doesn't contain a child! That simply must be a bug.

I admit it is not the largest bug in the world, but the consequence of a bug like this seems larger than I first thought.
As the xml and ui components both are a part of the platform, the solution seems to be an upgrade of the flashplayer as Adobe fixes the bug. Upgrading the flashplayer is something the enduser as to do.

As I am working on a internal flash/flex application that has to run in a closed environment, where ugrades of the flashplayer are something that is out of the hands of the enduser, an upgrade of the flashplayer may not be a trivial process.

A "watercooler talk" led to a interesting suggestion to how Adobe could structure the platform to lower the impact on the end user.
What if the xml api was some kind of versioned module that your flex application dependend on?
Then you (as a developer) just had to change your internal dependencies as bugfixes and new features was available.
Adobe could have something like a centralized repository existing of original (signed) modules.

The local machine running the flex application could have some local repository for downloaded dependencies. Each dependency could be resolved at runtime and downloaded as needed.
That would lower the time it takes for adobe to release a bugfix, as it doesn't involve a complete new flashplayer release and the issue where endusers doesn't have the privilege to upgrade a plugin is gone as well.

If the idea looks like the java/maven dependency architecture it's not a coincidence :-) Maybe flex /flash could learn from the java world in this case.

No comments: