fx

Whats with the ‘Fx’ prefixing?

October 29, 2008

If you follow the commits in the Gumbo SDK trunk, you may have noticed that about a week ago, a series of name changes were checked in. Additionally, a bunch of Gumbo specs and the Gumbo component architecture whitepaper are being updated on the Flex open-source site to reflect several name changes. A big chunk of these name changes were polish – temporary names like ‘skinZZ’ were changed to something less embarrassing (‘skinClass’ for those who want to know). Additionally, our API review board (yes, we care that much!) blessed many of the Gumbo ActionScript API’s and this resulted in some API changes that finally got checked in. But, the big change, which drove our build-engineer insane for a few days, were the numerous class re-namings that were checked into trunk.

Let me rewind for a second.

Gumbo introduces many new classes, and some of these new classes are re-implementations of existing Halo classes. For example, there’s a Gumbo Button and a Halo Button that follow the Gumbo component architecture or the Halo component architecture respectively. Prior to the name changes, the Gumbo Button lived in flex.components.Button while the Halo Button lived in mx.controls.Button. Collisions were avoided by the use of packages and namespaces. Namespaces in MXML are used to specify the language version and provide scope when mapping MXML tag names to class names. In Flex 2 and Flex 3, the MXML 2006 language namespace (http://www.adobe.com/2006/mxml) contained mappings for all of the Halo components. With Gumbo, we introduced the MXML 2009 language namespace (http://ns.adobe.com/mxml/2009) which introduced mappings for all of the Gumbo components and the new Flex graphics primitives. So, by cleverly using namespaces, you could write an application that inter-mingled Halo and Gumbo components, like so:

<?xml version=”1.0″ encoding=”utf-8″?>
<Application xmlns=”http://ns.adobe.com/mxml/2009″ xmlns:mx=”library:adobe/flex/halo”>
<mx:Button />
<Button />
<Rect width=”100″ height=”100″>
<stroke>
<SolidColorStroke color=”0xFFCC00″ weight=”5″ />
</stroke>
</Rect>
</Application>

This markup would create a Gumbo Application where the first child was a Halo Button, the second child a Gumbo Button and the third child a new Gumbo rectangle graphics object. Note, in that example, the ‘mx’ prefix is associated with a library url that points to a Halo manifest that contains only the Halo mappings. That prefix is used to disambiguate the two Button tags, and instantiate a Halo button when the MXML tag is prefixed with ‘mx’.

After a fair amount of back and forth between FlexBuilder, Thermo, and SDK alike, we figured all of this namespace stuff was too complicated. It became clear that though packages and namespaces were useful features for disambiguation when a collision occurred, using them as a crutch to allow collisions to occur when they could be prevented was wrong. After running through several options, we decided that prefixing new classnames to avoid collisions was they way to go. The prefix we chose was ‘Fx’ and this change is currently reflected in the Gumbo SDK trunk. The main “pro” for prefixing was that we could unify the Halo and Gumbo mappings into a single namespace, the MXML 2009 language namespace. So, under the MXML 2009 language namespace, you can instantiate a Halo Button the way you always have, via the <Button /> tag and you can instantiate a Gumbo Button via the newly prefixed MXML tag, <FxButton />.  Similarly, the new animation classes in Gumbo also follow this prefixing policy. A Halo resize effect is instantiated via the <Resize /> tag while a Gumbo resize effect is instantiated via the <FxResize /> MXML tag. Those tags totally new in Gumbo, like the Flex graphics primitives, don’t need any special prefixing since they do not have equivalents in Halo.

So, the example above should now look like this (in order to compile in the current Gumbo SDK trunk):

<?xml version=”1.0″ encoding=”utf-8″?>
<FxApplication xmlns=”http://ns.adobe.com/mxml/2009”>
<Button/>
<FxButton />
<Rect width=”100″ height=”100″>
<stroke>
<SolidColorStroke color=”0xFFCC00″ weight=”5″ />
</stroke>
</Rect>
</FxApplication>

We’re currently working on bringing our specifications up to date to reflect these name changes, as well as other class re-namings so please bear with us for about another week and things on the Gumbo open-source site should be up to snuff.

Thoughts, questions, concerns? Comment away!

–ADDENDUM–

Wow, love the passion!

Let me take some time to enumerate the reasonings and complexities behind the prefixing decision. There were 3 obvious hardships that came out of investigating using namespaces and packaging for disambiguation:

1.CSS namespaces
We would have had to have introduced namespaces in CSS in order to distinguish styles applied to a Halo component vs a Gumbo component (since type selectors use the leaf name of an MXML tag). Introducing namespaces in CSS is a beast – very tricky for the compiler and the tools. Developers would have needed a new CSS syntax to target styles for sets of components based on the namespace of the component set. This would have required updating the internal CSS parser to be aware of CSS namespace syntax, at least for element selectors, as well as updating the Flex compiler to track style namespaces. Additionally, support would have to be added such that Flex styles could, at runtime, be updated to handle namespaces. Even if all of this work was undertaken, other issues crop up. Since CSS does not support packages, if we tried using packaging to distinguish styles applied to a Halo button vs styles we want applied to a Gumbo button, like so:

mx.controls.Button
{
}

flex.components.Button
{
}

we would still be out of luck because dots (.) in CSS have pre-existing meaning. And, if we did add CSS namespace support, migrating pre-Gumbo code to Gumbo would be more difficult, something we try to avoid when possible. Additionally, there is an inherent trickiness with avoiding code bloat when depending on namespaces to control style inclusions. Because of naming collisions, you’re almost guaranteed to bloat your SWFs due to styles for one component being pulled in even if that component wasn’t in use in your application.

2.ASDocs
Providing clear documentation by using namespaces or package names for disambiguation would be difficult. We need to provide documentation for both Halo and Gumbo classes (Halo is not going anywhere till Gumbo has full functional parity with Halo). If we used packaging to differentiate, you would have to look in different directories for documentation depending on which control, Halo or Gumbo, you wanted to reference. If we used namespaces for disambiguation, you would then have Button/Button or CheckBox/CheckBox living in the same directory – one entry providing documentation for the Halo Button, the other for the Gumbo Button. We already have anecdotal complaints around the RPC services which used packaging to differentiate RPC base classes from RPC classes enhanced for MXML use, and don’t want to repeat those mistakes again.

3.ActionScript/MXML namespaces
Even if we used namespaces to aid in disambiguation, explicit scoping is still necessary. For example, in MXML, which namespaces are added by default? In the ActionScript world, when you write: var b:Button = new Button(), which Button do you mean? You either have to explicitly import the right Button class, or the system (code hinting) will have to prompt you to chose which Button you wanted to instantiate and add the explicit import directly. In the Gumbo timeframe, we are hoping we will improve code completion to assist with this so that you don’t have to type ‘Fx’ all the time. Imagine a code-hinting world where you type ‘Bu’, and ‘FxButton’ and ‘Button’ drop down. Completing that will insert FxButton; if you meant to instantiate a Halo Button, you just have to select it in the code hinting dropdown.

These 3 hardships defined a burden on the developer (as well as compiler, tools, and documentation generators). Additionally, the fact of the matter was that namespaces, though they help to disambiguate when a collision occurs, don’t actually *avoid* collisions all together. Onus is still on the developer to decide which component they meant to instantiate. Prefixing actually avoids collisions all together.

Because namespaces and packaging didn’t eliminate these problems 100%, we chose the prefixing route. Now, we don’t love it ourselves – there are definitely people on the team who dislike prefixing for a lot of the reasons described in the comments. You would be surprised at the hundreds of man-hours that have been spent on this issue, and the prefixing solution was the one ultimately settled on. While I can’t say that the prefixing solution is temporary, if a better or more elegant solution comes up, you  bet we’ll consider it. But right now, in order to avoid bulking up SWF’s, avoiding hard to track bugs, and adding CSS and tooling challenges, we settled on the prefixing route for collision avoidance.

And finally, I didn’t make this clear in my post, but the rule about what is decorated with an ‘Fx’ prefix is as follows: If the component is a *skinnable component* in the new Gumbo architecture, it is prefixed with ‘Fx’. Now we did break this rule in one place, to avoid collisions between new Gumbo animation classes and Halo animation classes, but that general rule stands firm. So, in future versions of Flex, when we add a new skinnable component, it will be prefixed with ‘Fx’. As for why there are other classes new in Gumbo that are not prefixed, that is because they are not skinnable components in the Gumbo architecture but instead are graphic elements, new classes, etc.

57 Comments

  1. Tink says:

    “Let me take some time to enumerate the reasonings and complexities behind the prefixing decision. ”

    As Ted would say, here’s my 2 cents.

    1. seems to make sense and I don’t know how you’d address it.

    2. You already have this. o.e. take a look in the docs for HTTP service. 1 for MXML, 1 for AS.

    3. Most of use I would have thought all have our own implementations of components, or other 3rd party components. You get prompted with a list of options that fit what u type, and select the one u want. Easy!

    Also using fx? I mean that stands for Flex right? This sounds pretty limiting, what would you use next? Sound as naff as mx was back in the day.

  2. polyGeek says:

    I say go with whichever approach makes it easier for the Flex Dev team to churn out great stuff faster. Sounds like that’s the prefix approach. No, it doesn’t look as pretty in the code but I can deal with that.

    One thing of note: it’s much easier to type ‘fx’ on a Dvorak keyboard than on a QWERTY. For me it’s like everyone else typing ‘yb’. So yet another reason for people to switch. :)

  3. [...] By tim Some members of the community around Adobe’s open source Flex SDK are fuming at a decision made by Adobe back in October 2008, to prefix the new skinnable components in the forthcoming “Gumbo” release with Fx. This means [...]

  4. Marcus Stade says:

    Point 1:
    CSS? Really? That’s the excuse?

    The CSS support in Flex is not even standardized CSS, so I’d imagine there’d be little reason to argue against implementing custom CSS features such as *gasp* namespacing. C# has a nice way of disambiguing between types of the same name used in the same document, something similar could definately be used in CSS as it would blow the OMG-theres-so-much-work-to-port-our-CSS-to-Gumbo argument out of the water:
    /* Begin css snippet */

    using Button = mx.controls.Button;
    using FxButton = fx.controls.Button;

    Button
    {
    /* Whatever styles apply to the old crappy buttons */
    }

    FxButton
    {
    /* Whatever styles apply to the new funky gumbo buttons. No really, Gumbo rocks! */
    }

    /* End css snippet */

    Fact of the matter is, these issues will always show up and is why we even have namespaces in the first place. It’s silly beyond reason to prefix class names but if that’s what you guys HAVE to do in order to get Gumbo out the door on time, then by all means prefix the OLD component sets with Mx or whatever (also not ideal for reasons I will explain later).

    Point 2:
    The ASDoc argument is moot. Make use of the [Deprecated] attribute and mark any such classes apropriately in ASDoc, sorting them with less priority and you solved the issue:

    Button
    [Deprecated] Button
    HSlider
    [Deprecated] HSlider

    It doesn’t look all that pretty, but marking the classes deprecated means you have the necessary meta data available to do proper filtering. Tick a checkbox to hide deprecated classes and there you go, problem solved. Naturally, the meaning of the attribute Deprecated is to convey the fact that the class will itself disappear in the next version of the framework. This ensures that code bloat will not happen since you allow the graceful exit of old classes. What you effectively allow with prefixing the classes however IS code bloat. Deprecated classes are deprecated for a reason and should be removed from the codebase as soon as possible. Besides, this support is already implemented, the compiler already recognizes this. There’s NO REASON WHAT SO EVER to ignore that fact.

    http://livedocs.adobe.com/flex/3/html/help.html?content=metadata_3.html

    Point 3 that you mention is just grasping at straws. You can’t seriously mean that in order to facilitate the IDE you’re changing the framework. That’s about as absurd as it sounds. It’s not like “Button” is the only data you have available to you when building the code hinting information, and even if it was, you’re problem is not types of the same name anyway.

    It really does seem like you have detached yourselves from the grips of reality. Flex is an excellent product, light years ahead of the competition. Ignoring this issue is an embarrassment and a slap in the face to your developer community. I LOVE Gumbo, the new skinning architecture makes so much sense. The new and improved CSS support is lovely. It’s starting to look more and more like a proper development ecosystem. Ignoring namespaces makes it, and Adobe, look silly. Not for naming the classes wrong, but for not understanding the concept of namespaces. It’s one of those things you’d expect the developers of a framework to grok.

    Blaming the decision to forgo namespaces altogether on the complexity of the compiler is even more embarrassing and it ignores the ACTUAL issue completely. It might not be trivial to implement, but please try to consider the alternatives from a real world perspective, your customer’s perspective. This problem is not new and have been solved ages ago (it’s answer is namespaces). It is entirely possible to do away with namespace of course, many frameworks have done it in the past. Take a look at Apple for instance, they have code like this all over the place:

    NSString
    NSMutableArray
    NSDictionary
    CDCRecipient
    CDCEmail
    CDCEmailAttachment
    CDCTableView
    CDCOutlineView
    CDCArrayController

    Yeah, works out fantastically well. Best of all, it’s scalable:
    FXNSCDCABCFOOBARButton

    Hungarian notation anyone?

    What really scares me are the rules-but-not-really-that-are-side-effects-of-this-silly-decision-to-forgo-namespacing:
    “Now we did break this rule in one place, to avoid collisions between new Gumbo animation classes and Halo animation classes, but that general rule stands firm. So, in future versions of Flex, when we add a new skinnable component, it will be prefixed with ‘Fx’. As for why there are other classes new in Gumbo that are not prefixed, that is because they are not skinnable components in the Gumbo architecture but instead are graphic elements, new classes, etc.”

    So essentially, it’s not a rule then? It became inconvenient with animation classes, what’s to say there won’t be other classes where inconveniance will yet again become an issue?

    Please try to understand that you’re actually missing the point in this issue. Prefixing classes makes things more confusing in the long run. What’s even worse is that you then condone the use of classes and components that may well, going by the suggestions in your text, disappear at some point! This is a migration nightmare waiting to happen. Let’s for arguments sake you do go with the prefix route and people start using Halo and Fx components together, not knowing they’ll go away in Flex 5 (ficticious name). Now when Flex 5 rears it’s head and you again ask your customers to migrate (and they should!), you’ve effectively painted yourselves into a corner. Because remember, Flex 5 did away with the Halo components, but you never issued any warnings about this (the sole purpose of the Deprecated tag) so companies have developed these huge codebases on the assumption that they could take the datagrid from Halo and use with all the fancy pants magic going on in Fx. Using the deprecated tag, you still allow this, but issue proper warnings. This will actually EASE the transition from Flex 3 to Flex 4 (and subsequently Flex 5) instead of the prefixing solution (hack, if you will) which will merely be confusing, at best.

    I sincerely hope that Adobe changes it’s mind before committing to this huge mistake.

  5. Folks, please note that we ARE revisiting the prefixing issue, in favor of namespaces. Matt Chotin posted the current proposal/thinking on the user forums on the Adobe site. Please refer to that for discussion and to add your own commentary.

  6. saran says:

    Hosting Problem

    i am using force.com flex toolkit to retrieve datas from salesforce to flex 3….in flex builder i am able to retrieve the datas but when i hosted to server its not retrieving the data can anyone guide me how to solve this problem

Leave a Comment