Gumbo Namespace Changes – Revisited
I posted last week about how the namespaces had been altered in Flex 4 using the gumbo components. The problem with posting detailed information about a product that is so early in its life-cycle is that large changes can be made in the wink of an eye.
An example of this is that while the earlier version of the sdk separated the language namespace and component namespace, those items have now been combined. So just like with flex 3 you must only specify the language URI to access all of the components in the language, halo, and gumbo namespaces.
My previous example has been updated below.
1 2 3 4 5 | <?xml version="1.0" encoding="utf-8"?> <Application xmlns="http://ns.adobe.com/mxml/2009" > <FxButton label="Gumbo Button"/> <Button label="Halo Button" /> </Application> |
As you can see with the namespace prefixes removed there was a class name conflict between the Buttons in halo and gumbo. As a solution all of the gumbo components have now been named Fx[classname]. FxButton or FxCheckbox for example.
I hope this may help clear up some confusion around my previous post. It appears my timing could not have been better. No sooner had I written my post about the namespaces… they changed.
I truly hope that the compiler is smart enough to know when an application has only Flex 3 or Flex 4 components, otherwise applications will now have to include both sets of components in the compiled build even if they are only using Flex 3 or just Flex 4 components. Ideally, developers will use the SWZ framework files for the application to prevent re-downloading but I really liked the concept of explicitly stating what component version I am using via the namespace.
As you pointed out in your previous points, the existing Flex 3 workflow had some issues and lots of special cases and this new structure clarified it. It may appear a little more complex but the first Flex 4 way felt more elegant and provided better granular control. Flex developers already have to come to terms with namespaces when creating custom components and the previous Flex 4 linking followed this pattern: Use a namespace to define your library / resource.
On top of that its hard enough to explain component sets to new developers and designers but now you have to say explicitly use the FxButton not a Button and then explain what an FxButton is. I guess there is potential for confusion either way but explaining that there is a new Button that has a new name is not as clear as saying there is a new version and we can either use the new one or the deprecated one.
Finally, what happens when Flex 6 comes out with a new structure? Will we call it Button since by then FxButton is accepted as the default button or will we call it FxFxButton? (okay, I am being a little facetious here)
Oh man…
Gumbo is so hot but this whole ‘FxVersion4Button’ thing is really throwing in some chilly water on it.
It’s hard to believe that millions of Flex developers of the future will have to type hundred times a day just because of some legacy Halo stuff which most of them will not even get to use in the first place.
I haven’t had the time to delve into the logic of this but from the uneducated user’s perspective it totally sucks.
Hi Jay,
What you need to explain to the user is ther are 2 frameworks in Flex now.
Adobe just added a new framework branch that uses an entirly DIFFERENT layout algorithm and skin implementation.
The naming of theses new components had to be done. When you are using anything prefixed with Fx, this means you are in a branch framework that does not work at all like the halo framework.
From a software architect point of view, this was neccessary and there was no way around it.
In the long run this is going to pay off in clarity.
Mike
In the process of refactoring the component names and other changes in the past couple weeks, it appears that code completion for many components is now not working…grrrrrr.
Hey Rick,
So there is a trick with this. Although they want to use no namespace for the code in gumbo if you do use a prefix you will get code completion.
So stick with mx: or add a new one and you should be ok. An update to flex builder will fix this I am sure.
sim
Hi, Sim.
Thanks for the response. Actually, the gumbo components *do* get code completion – it’s the halo components that don’t.
Adding a dummy namespace declaration (mx) did seem to bring the code completion back for the halo components as long as they’re prefixed.
Hmmm….
Rick
I have noticed that ColdFusion wizards generates xmlns=”*” into the application tag. This seems to be a compiler directive, but I have not determined its purpose.
Also, wouldn’t this likely change under the Gumbo namespace proposal?
Hey Doug,
The xmlns=”*” says to import any components in the same directory as this file and let me use the tag names without a prefix. That will conflict with the proposed changes in gumbo, so the cf wizard will likely have to change how it outputs its code.
HTH,
sim
Hi Simeon,
I read both “namespaces had been altered in Flex 4″ and “Gumbo Namespace Changes – Revisited” you wrote. You said in the first post “Because the tags used in the language namespace and the component namespace were combined in Flex 3″. May I consider that the two kinds of namespaces are also combined in Flex 4? But actually the two kinds of namespaces do exist in Flex 4. Thanks