Fx prefix in Gumbo revisited

Aral Balkan blogged about what he called an epic FAIL of removing the Fx prefix from Gumbo.

This I admit came as a bit of a surprise to me as it has been widely discussed in the community for some time and strong consensus built around using namespaces. The decision was then made by Adobe on February 13th 2009 to drop the Fx prefix and go with namespaces. For those that aren’t really getting this whole controversy, its actually quite simple.

 
Initially the idea for the next release of Flex (codenamed Gumbo) was to leave out namespaces for the new components and instead use an Fx prefix. As you probably know up until now we had the mx namespace for Flex components which was like this:


  

 
The Fx prefix approach looked as follows:


  

 
The new approach with namespaces looks as follows if you want to mix and match between the old Halo and new Spark components.



  
  

OK, now I see how that can look a little more confusing — what in fact is happening here is that you set up a language namespace (there can be only one) that defines how your MXML gets parsed and compiled.

Then for any set of components you use (as you might already be doing for third party libraries) you create a namespace. In this case one for the Halo components “mx” and one for the Spark components “s”.

Why do I believe this is a good thing? Prefixing component names is not a sustainable option, in a next release you would have to go with a different prefix, i.e. Fx2Button. I don’t see a huge use case of people mixing various versions of components (update: as rightly pointed out by Asger in the comments, since Form etc. are mx only at the moment you would in many cases be required to mix namespaces). This sort of reminds me of what you had happening in Flash with fscommand and fscommand2.

Namespaces are a common standard, they’re implemented in the language and are good solution to avoid naming conflicts. Simplicity in syntax is one thing, I think the pragmatic approach here is seeing how things will evolve and not painting yourself in a corner.

I believe there is room for improvement but structuring MXML around namespaces makes complete sense to me at this moment in time. Moving forward there’s something to be said about using naming conventions to abstract the underlying concept of namespaces. If and when the tooling (i.e. Flash Builder) is up to scratch, this whole process should be seamless for developers and not that different from how you had things in Flex 3.

 
More information here:
http://opensource.adobe.com/wiki/display/flexsdk/Dropping+the+Fx+Prefix

 

Advertisements

8 thoughts on “Fx prefix in Gumbo revisited

  1. I agree, though I would say that in terms of Flex 4, there *will* be a lot of use cases where you would mix mx: and s: name-spaces.
    Forms, RPC etc., is still mx: only components thus, would have to be intermixed with the new name-space.

    I’m all for name-spaces, and one way to go about clearing out what is what could be a supporting IDE which color coded the various name-spaces differently.

    Cheers

    Asger

  2. Peter says:

    Good point Asger, in an ideal world we would of course have a complete set of Spark components — but right now its true that you’re more or less forced to use multiple namespaces.

  3. Aral Balkan says:

    Peter,

    Also mention that this will mean that _existing code_ cannot be reused without making changes. So if you’re using five different libraries and maybe a couple of skins you’ll have to go in there and add namespaces to everything, including the CSS.

    With the Fx prefix, you could just drop your existing code into your project. Wanna add a Gumbo afterwards, go right ahead, just add it, no need to change anything. Wanna use a skin created for Flex 3, no problemo.

    ^^^ All that’s lost with namespaces.

    These are real, _practical_ reasons for why this change is a step backwards. I’m not talking about aesthetics of formal beauty here but pragmatism.

    It also adds additional complexity that will confuse newer developers and make it harder to learn the framework. That’s great news if you’re writing books (because they’ll have to buy more books to read about this confusing stuff) or if you’re a consultant/advanced developer (you can charge more and get more work and dazzle people by knowing all this complex stuff) but not great news if you’re just getting into Flex, evaluating it against similar technologies or if you’re concerned about the competitiveness of the platform and future adoption rates among developers.

  4. TJ Downes says:

    Aral, your concerns seem to assume that the average developer learning Flex, who had the capability to learn Flex 3, would find Flex 4 to be significantly more difficult. I don’t really buy into that. I believe most people who want to learn Flex are considerably bright enough to figure these things out.

  5. Ben Stucki says:

    Aral, There are those of us in the Flex community who are involved out of a (*gasp*) passion for developing apps with Flex. So let me assure you that no one in the vocal minority was motivated by convoluting the framework in an attempt to look smart or make money. I’m frankly disappointed by these stray comments you’re throwing out, and I’m finding it difficult to address the valid concerns in the midst of them (which were much debated over). I think we’re all interested in seeing the framework succeed, so let’s keep it above the belt shall we?

  6. jay says:

    @Aral:

    ” not great news if you’re just getting into Flex ”

    I don’t know about new developers… try convincing a young developer who is just out of school/college and has been already seduced by the OSS trenches that he should be targeting a proprietary platform.

    Ok, now on top of that try to convince him that his applications cannot have Buttons, Datagrids and Forms.

    It must have FxButtons, FxDatagrids, and FxForms… oops, you probably lost him by now… 😀

    Anyway, my point is really that argument for productivity is a good one but it’s not the only one and many times is not the ultimate reason on which software platforms are chosen.

    The fact that so many people choose open software and standards over proprietary ones stands also as testament of this, as proprietary software many times offer better productivity, but still the lower risk and long term benefit of OSS has historically proven it’s value.

  7. Tink says:

    Maybe I’m missing something here, but I don’t understand why they didn’t just add 1 new namespaces for the Spark components.

    i.e. why didn’t the mx namespace stay as

    xmlns:mx=”http://www.adobe.com/2006/mxml”

    and just add a new one for Spark

    xmlns:spark=”library://ns.adobe.com/flex/spark”

    so that all code was backward compatible. You’d only have to add a new namespace to you code, if you decided to implement one of the new Spark components.

    I thought the main issue was that it was to be backwards compatible.

  8. I tend to make my ‘own’ components based on the components provided by Flex. This way I only have to change the base class of ‘my’ components and everything works fine again. Using only your ‘own’ components you can fix flaws (like the focus border not being drawn when giving focus using the mouse) in 1 central place.

Comments are closed.