[UPDATE: Much of what I discuss here is still relevant but in a recent update to the sdk the namespaces have all been combined. Please follow up this post with the update. Please don't try to run the code from this post. View the updated code here.]
In a previous post I showed you how to get Flex Builder set up for building applications using Flex 4 (Gumbo). With your development environment ready, there are some fundamental changes to the namespaces used in developing flex applications that you should be aware of. And while these changes are all for the better, they do add some tricky complexity to the task at hand: building flex applications with gumbo.
When developing applications with the Flex 3 the standard namespace has always been “http://www.adobe.com/2006/mxml” used with a prefix of mx. While it appeared the purpose of this was to allow us to specify the version of flex to the compiler, this was not what was really happening was behind the scenes. While this is not completely wrong, the compiler used that string (not really a url) to look up the correct manifest file. The manifest file provided a one-to-one mapping of tag names to component implementations. There was a problem with this however, because not all tags used in mxml documents have a corresponding ActionScript implementation. Tags like < mx :MetaData />, < mx :Binding /> and < mx :Model /> are tags that are language tags. These tags represent items that need to be handled in a specific way by the compiler. Because the tags used in the language namespace and the component namespace were combined in Flex 3 you may never have known there was any difference between the two. And you really did not need to for normal Flex 3 development.
One of the primary goals of the Flex 4 SDK is backwards compatibility with the existing Flex 3 applications. What this means is that while there are many improvements already begun and more in the pipeline, none of those can break existing functionality. Because some of the new code updates existing classes (Button for example), we need to separate the component namespace from the language namespaces. Because while we can use multiple component namespaces at the same time ( mx and your custom component namespace for example in flex 3) you can only have one language namespace declared.
Because of this change you can now declare the language namespace for flex 4 as “http://ns.adobe.com/mxml/2009″ and then use the new library URI’s to reference the halo (flex 3) and gumbo (flex 4) component frameworks as “library:adobe/flex/halo” and “library:adobe/flex/gumbo” respectively. For convenience sake the gumbo library is also included in the mxml 2009 language namespace.
1
2
3
4
5
| <?xml version="1.0" encoding="utf-8"?>
<Application xmlns="http://ns.adobe.com/mxml/2009" xmlns:gu="library:adobe/flex/gumbo" xmlns:mx="library:adobe/flex/halo">
<gu:Button label="Gumbo Button"/>
<mx:Button label="Halo Button" />
</Application> |
So if the gumbo component namespace is included in the language namespace for flex 4 why would you include it separately? Well the first reason is a matter of clarity. Since you can use either halo or gumbo and you can mix and match, then specifying your component namespace serves to disambiguate those components in question. This also allows the developer to see a clear line between what components are implemented in ActionScript and which are provided for compile time tools. The second reason is actually purely for the developer. If you specify the gumbo namespace then Flex Builder will provide code completion for your tags. While your code will compile and run, Flex Builder will not provide code completion for the components when you only specify the language namespace for mxml 2009.
The separation of the language namespace and the component namespaces also allows for upgrades of the two separately, which may seem unnecessary, but so did release flash player without the Flash IDE at one point. But now we know that the separate entities can prosper on their own, and this opens the doors for external tools to work in the language namespace with much greater freedom.
Tune in soon for another post on the new elements in the language namespace and how they effect the development of your applications.