Joeflash’s Enigmacopaedia


Say NO! to Fx class Prefixing in Gumbo

Posted in Flex, Flex 4, Gumbo by Joeflash on the October 30th, 2008

It is with great concern that I have learned on Deepa’s blog that Adobe will be going forward with the FxClass prefix naming scheme for Gumbo and ditching namespaces for Gumbo components. It sounds like others aren’t too thrilled about it either. I’ve logged feature request SDK-17854 on the Adobe Bug System, so please vote for it if you think namespaces are a better idea than class prefixing.

The reasons I don’t think it makes sense to adopt a Fx class prefix instead of a new namespace are:

  • It introduces inconsistency in the implementation of the MXML 2009 specification (which will be updated with this change soon).
  • It reduces the amount of choice offered to developers, and the flexibility of the Gumbo workflow. With namespaces, the developer has the option of choosing their own namespace name for the Gumbo and Flex 3 components, or omitting the namespace altogether if they wish.
  • It’s not intuitive. Having to remember that I have to type FxButton for a Button class, every time, even if code completion helps me type the “Fx”, forces my overloaded brain to work that much harder.
  • It will create forward compatibility issues. What will they name the Flex 5 components? <Fx2Button /> ? <GxButton /> ? Adobe, think of the children… : )
  • It makes Flex harder to learn for beginners. Having trained many Flex beginners and written many beginner Flex tutorials, I can say unequivocally that introducing an inconsistency in the specification at such a core level will present yet another Flash Platform “Quirk” for beginners to cram into their heads, and will make Flex 4 harder to learn for beginners (if only by a small bit). I’m not saying it will be a deal breaker, but Adobe won’t be doing the Flex 4 adoption rate any favours.

What I’ve proposed in the feature request is that Adobe keep namespaces for Gumbo components, and introduce some added intelligence in the code completion to make it easier to avoid mistaking <mx :Button/> for <fx :Button/>

Please go vote for it and change Adobe’s mind on this one.

4 Responses to 'Say NO! to Fx class Prefixing in Gumbo'

Subscribe to comments with RSS or TrackBack to 'Say NO! to Fx class Prefixing in Gumbo'.

  1. Rick Winscot said,

    on October 30th, 2008 at 4:45 pm

    I understand and can sympathize with your arguments… have you considered the frameworks lack of backward compatibility? Not to mention the size of the framework if, in the same codebase, all versions of the framework must be supported? In the Flex 3.1 SDK source I’m already seeing quite a few switch statements against the components version number.


  2. on October 30th, 2008 at 6:29 pm

    Please check out my updated explanation:

    http://iamdeepa.com/blog/?p=34#comment-957

    as it provides a lot more information behind the prefixing thought process that are not as obvious to people initially approaching the issue. There is a lot beyond just how Gumbo components will look in MXML.

  3. Juan Sanchez said,

    on October 30th, 2008 at 9:27 pm

    One thing I could see issue with is in CSS Type selectors, since both components handle skinning differently. Using the Fx prefix gets rid of the issue when mixing both components. Just one observation.


  4. on November 24th, 2008 at 1:32 am

    We’re in the process of determining ways to give Fx components more visibility in code hinting and other places in the UI of Flex Builder. If users can’t find them, they won’t use them. And if they do find both, we want to avoid any confusion regarding which component to use

Leave a Reply