[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.
9 Responses to “Understanding the namespace changes in Flex 4 (Gumbo)”
Trackbacks/Pingbacks
- Ryan Stewart - Rich Internet Application Mountaineer » Blog Archive » Figuring Out the New Namespaces in Gumbo - [...] Bateman has a really good post up about some of the changes that we’re making to the namespaces for ...
Thanks again for another good update. This seems to make sense, at first I was thinking ‘oh great here we go..’ but this should work out fine.
The multiple filters guy from the UGM Meeting in San Jose .
It’s worth checking out Ryan’s latest post too because we’re updating the names of components in the new model to have an Fx prefix. This is going to allow us to have components side-by-side, which means we can include even more in the MXML 2009 namespace. This is primarily about convenience, the compiler is even better set up to understand the difference between language namespaces and component namespaces, it’s just that we don’t need to introduce separate library namespaces by choosing our naming the way we did and we feel like most folks will have an easier time if we try to keep things to one.
I saw that the flex package had been renamed and the Fx prepended to the the Classes that overlapped. I actually hoped that was some kind of transition state and not the final and intended result.
Developers are used to using prefixes to include different sets of code into their application. They do it with their own components. They do it with Degrafa. They can do it with gumbo.
I liked the separation of the namespaces and would rather see halo and gumbo as separate component libraries that can be used in conjunction with our own. I really liked that gumbo felt like a new lib we could build on and not more core integration that we had to contend with.
Since we will always need our own namespaces for our code, I really liked the idea of gumbo being implemented in a similar manner. I see the separation of namespaces as something that makes our code clearer and not merely as a point of convenience. I would much rather see fx:Application vs mx:Application than FxApplication vs Application. I feel the prefix and seperate package present a much clearer picture of what is actually going on.
+1 for the namespace solution. As already commented in Ryan’s blog, it seems much cleaner to me (especially as namespace support is already there).
To me, the Fx-prefix just feels more like an improvisational hack.
S.
Hey Sebastian
You and I are on the same page on this one. After talking to Matt offline about this it seems the name changes were actually driven via the need to style the components from the two frameworks independently. But with the classes sharing the same name this is a problem.
I hope that this is something that will change before the real releases but we will see.
Hello Simeon,
thanks for that information. However, I am still not sure whether I see the need for the named prefix, too. This sounds a bit like “you cannot reference namespaces for styling” which seems a little confusing to me.
Best regards,
S.
I can’t seem to get this to work. I get the error ”
Could not resolve to a component implementation.” Same for the mx button. Any idea what I am missing?
Yes, I know exactly what is likely to be wrong. The problem with working with pre-release code is that the peices that make it work can change at any time. All of the classes which have a name conflict between gumbo and halo have been renamed in the flex 4 sdk.
So Button is now FxButton. The Fx must be added to most of the gumbo components. I will update this code right now.
sim
I have posted a follow up to this with updated code sample here.
http://blog.simb.net/2008/10/13/gumbo-namespace-changes-revisited/
sim