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.
I have to say I really, really don’t like the prefixing. I think it reduces the “skimmability” of the code because you have to read that much more of each tag to know what it is. While admittedly minor, it also means typing 2 characters more on every single class/tag.
I also think if you are going to use prefixes, use them on everything. Some with and some without just feels inconsistent.
Finally, do you really think people will be mixing Gumbo and Halo components in the same file that often? Obviously lots of apps will contain both but I wouldn’t expect to see many instances where a single file will include both. For the rare cases where they are mixed, I think namespaces and packages would suffice.
Personally, I don’t like it. You’re just trading one prefix (mx:) for another (Fx), but this time you’re requiring it in all cases and putting it on the shiny new stuff instead of the old stuff.
The most important advantage I see in separate namespaces is that if Flex ever moves to 100% Gumbo-style components (and I’d like to think that it will, eventually), then we can just stop using anything in the mx namespace and our code will look nice. Seeing a file with the Fx prefix over and over will make me (and other like-minded developers) cringe at the thought that we typed an extra “Fx” a thousand times today. In Flex Builder today, with the Halo components, I don’t have to type the mx: because code hinting is smart. Will it be as smart if I want to skip the Fx? Should it be, or is that as hacky as it seems in my head?
In short, I’d very much prefer to see the mx: stick around for Halo. It’s already a part of life now, so we’re used to it, and once it’s fully deprecated, Gumbo won’t make my files look like they’ve been infected with a nasty Fx disease.
I dont like the idea of the Fx prefix. The 2 separate namespaces seem to be the way to go.
Also, it is not immediately apparent from your post what is wrong with having 2 namespaces. You say “using them as a crutch to allow collisions to occur when they could be prevented was wrong”..How exactly is this a crutch and what is wrong with it? Could you help shed some light on that thought process ?
completely agree with the previous comments. I liked the namespace approach better. I’d rather see:
mx:Button and fx:Button rather than forcing the prefix on the class name.
@Ben: We do expect people to be mixing Halo and Gumbo components in their applications. This is because it will take us some time to get the Gumbo component set up to par with the Halo component set, so while this occurs, you can use the Halo equivalent if the Gumbo component is not yet available.
I am totally with Josh and Ben on this one and I am not a fan of the Fx prefix at all. I really liked the idea of using namespaces, infact this is exactly what namespaces are for. Namespaces also allow developers to determine the prefix allowing the code to be easier to read.
As Josh points out that when we move away from Halo and fully to Gumbo it makes it harder to manage. What happens with the next update of the components in Flex 6? FxFxButton?
Also, how will the compiler handle this? If we use only the Gumbo buttons with the compiler know not to link in the halo package? Will we have different SWZ files to manage this or is there one SWZ for it all? Having the package separation makes it much easier to determine what is being consumed.
What happens when a developer forgets the Fx name and automatically types the Halo version, or a new developer comes in and links to the wrong one? Tracking it down will be a lot harder, versus searching or changing the namespace. I felt the initial implementation made a lot of sense and I picked it up very quickly. I realize this was a big change but I hope the team reconsiders this change and moves back to using namespaces.
I don’t like the idea of prefixing the new classnames, it is really confused since some classes are prefixed while some are not. I think the use of fx as the namespace for the tags would be a better idea. In case of naming collision, why don’t simply use the Gumbo classes only in Flex 4 ? Since Flex 3 and Flex 4 are essentially different, why keep the legacy stuff ?
@James – SWF size is hugely important to us. The SWZ details are currently TBD, but nonetheless, we continually try to minimize interdependencies between Halo and Gumbo, so that if you only use Gumbo, you don’t incur the weight of Halo.
@Ben This is alluded to in the post, but one reason for this was around CSS. There’s no easy way in CSS to distinguish between mx.core.Button and flex.core.Button. Introducing namespaces in CSS is feasible, but it’s a little ugly, and it would make migration of old code harder. As per some with the “Fx” and some without, this is because some of the component names (Rectangle, Group, etc…) are set in the FXG spec and can’t be changed name-wise.
I agree with the others; I feel this is what XML namespacing is _for_, allowing us to mix and match schemes. Those coming newly into Gumbo – who will only learn and use Gumbo – shouldn’t be confused by having the Fx prefixes on the front. Presumably over time Halo will be phased out, leaving us with a very odd syntax.
I too prefer name spaces instead of Fx prefix. It gives the freedom of choosing your own prefix and looks a lot cleaner
Can someone enlighten me or point me to a good article about the real purpose of Gumbo, the real purpose having a whole new set of components similar to the old ones ?
I mean, what’s the point of FxButton over mx:Button ?
What were the triggers behind that decision ?
Don’t feel anger in my comment, just the doubts of someone not in the know. Would be thankful for good resources about that.
I assumed that Adobe would have focus on some usability improvement like for instance a real autocomplete behaviour for mx:ComboBox by default. or some easy automatic pagination on datagrids, … or a simplification of that whole heavy thing about ItemEditors/Renderers when numerous data providers with lookup data come into play.
I ‘m new to Flex and on a very simple project involving a main list with filters and subsequent create/edit foms with sub-lists of parameters.
I find huge the number of components that I had to extend to have some basic ergonomic usability. Alongside visual hacks like for instance, to have background gradients on a Hbox .
Well, I was wrong, do feel a tiny bit of irritation in my comment.
( main cause is a great feeling of time wasted googling for solutions).
If gumbo addresses all that, well then ok, forget what I just said and let’s welcome it. But then why not improving the existing components.
As you see, for a whole bunch of people (like me), you’ll have to make good marketing efforts to advertise the benefits and the switch to Gumbo. Especially with that kind of strange moves like this Fx prefix. I’m with Ben, Josh and James about namespaces over prefixes.
I just hope my rant is constructive. The point here is not to hurt feelings, you sure do great work. And as I said, i’m not yet in the know.
I just found http://www.mikechambers.com/blog/2008/08/27/everything-there-is-to-know-about-flex-4-gumbo/
which is a good starting point for me.
For what I’ve see things looks promising. But a lot of developers (conversations I had with fellow flexers allow me to say “a lot of” ) would have prefered to have “Data in mind” rather than “Design in mind” as a catch phrase.
A lot about visuals and design improvement at first glance.
you see, still ranting on about, cant’ help, sorry for that.
Is the Fx prefix permanent or will it be changed later?
I think having some components with an Fx prefix and some without is a huge mistake. You implied that the Gumbo component set will continue to expand over time which means that when “hunting” for a class, we’ll always have to check for the existence of a Gumbo “Fx+ComponentName” version first, and if it’s not there, look for plain old “ComponentName” instead. What if you guessed incorrectly about the name of the component? Rinse and repeat. This could cost even advanced users productivity, and worse, be completely baffling to newer users.
Don’t like it.
Doing so as others have pointed out, negates a useful feature of XML.
Now tooling has missed on potential features such as highlighting tags in a particular namespace, collapsing tags in particular namespaces, conditionally compiling in/out tags in particular namespaces…(off the top of mey head) stuff like that.
-1 Prefix.
If we were to mix and match a few halo and gumbo components in the same application, couldn’t this css problem be solved by:
mx.controls.Button
{
}
flex.components.Button
{
}
Not that that would be my favorite thing to do, but I’d much rather that then classname prefixes
I agree with almost everyone here. I think the Fx prefix is ugly and dumb. What happens in flex 5, are we going to need a new prefix again? “Fx2”, “Fxx”, it just gets out of hand? The namespaces make way more sense to me.
-1 on Fx prefix for the reasons already stated.
-1 on prefix, even though it’s already in the works. Thanks for sharing the info though!
The Fx prefixing looks inconsistent with the namepace spec, which is a lot more flexible for developers. With a namespace spec, I could assign the namespace to a wildcard and omit the fx: completely. So now with the Fx class prefixing, as a developer you’ve given me less choice of how I want to implement my component architecture, not more, so it has the feel of a hack versus a polished approach.
Why not keep namespaces, but simply have Gumbo components have an fx: namespace? The autocomplete can take care of typing fx: just like it does mx:.
Even if the autocomplete adds the Fx class prefix for me, I have to remember that I’m looking to spell FxButton for the Button class in the Gumbo framework. That’s wacked.
You’re just made the workflow more clunky.
Make the Fx prefix into a fx: namespace.
Please. For the children… 🙂
I’ve just created a feature request for this. If you dislike the proposed Fx class naming, please go vote for it.
https://bugs.adobe.com/jira/browse/SDK-17854
The CSS collision problem makes far more sense, and that’s a better reason to use different names than saying that it’s because Halo and Gumbo can now be in the same namespace. As many others here have pointed out, different XML namespaces are a non-issue for a lot of us, and namespaces are actually preferred.
I’d like to take a moment to add that I always thought Flex’s CSS was strange in that it completely ignored ActionScript namespaces. I never expected Adobe to run into collisions when I first thought about this issue because I figured there’d never be any reason for Flex to have two Button components. So much for that idea. Regardless, it still bugged me that I couldn’t make my own DataGrid or Button or whatever that had completely different styles because the name would collide with the main component. Lame. Lame. Lame.
Ideally, I’d rather see a better CSS that takes into account AS3 namespaces than the Fx prefix. I imagine that’s a lot of work, though, so we may just have to live with this Fx disease. *sigh* Still though, since some CSS changes are being made already, it might not be impossible.
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.
Now, let me start answering some comments directly:
@Ben: Yes, we do believe people will be mixing Halo and Gumbo components since it will take some time for the Gumbo component set to achieve functional parity with the Halo component set. Until that happens, we have a firm commitment to Halo and to avoiding collisions.
@Josh: Yes, one day we will have a framework with all the Halo components built in the Gumbo architecture, and all skinnable components used in the app will be prefixed with ‘Fx’.
@James: The next update of Flex will still use the ‘Fx’ prefixing for newly created skinnable components (unless we come up with a more elegant solution that allows us to abandon prefixing).
@James: Your question about what happens when a developer forgets the Fx prefix or a new developer links to the wrong one are valid, but those problems of instantiating the wrong component are much more prevalent in a system where namespaces are used for disambiguation because code hinting could easily allow the wrong component to be selected. See #3 above.
@Dev: Again, we have to keep Halo around till Gumbo achieves parity with Halo.
@David: Another good starting point for the Gumbo architecture is my whitepaper, here: http://opensource.adobe.com/wiki/display/flexsdk/Gumbo+Component+Architecture which illuminates the benefits of the new architecture. For the “why Gumbo?”, try tracking down Ely’s 2007 MAX talk or my 360Flex Atlanta talk. Slides are on the internets. As for why not “Data in mind” as a theme, this is definitely an area we’re working on, that unfortunately I can’t share with you yet. All I can say is: COME TO MAX!
@Devin: dots (.)have meaning in CSS so the package name cannot be used to disambiguate selectors as your example suggest.
How long is it expected to take for Gumbo to reach functional parity with Halo?
As for mixing in the same file, that could easily be avoided by moving Halo or Gumbo components to their own file and including that. Sure it might be a pain, but that approach is temporary right?
Why not prefix the old Halo components with Mx instead?
e.g. MxDatagrid, MxBarChart etc
Seeing they will be deprecated eventually in favor of the new “gumbo” model?
Is the plan that once Gumbo reaches functional parity with Halo will the prefix be removed?
For points 2 & 3 (ASDoc & MXML) it seems that there are possible solutions already hinted at.
It “seems” that the decision was more so based around the CSS issue.
Could the solution be in how the CSS is loaded?
eg. style.source = flex3.css and gumbostyle.source = flex4.css
I didn’t think about the css dot syntax…
what if gumbo components had default styleName of “fx”? Then we could do
/* mx.controls.Button */
Button
{
}
/* flex.components.Button */
Button.fx
{
}
You’d only need to do that if you were mixing the two in the same app. If you had 100% mx.controls.Button or 100% flex.components.Button, then just
Button
{
}
would work in both cases.
Or even better… since the idea is to eventually phase out the halo components, put the work-around on them instead of the the gumbo components. Make the default styleName of halo components be “mx”…
/* using pure gumbo components, so this works */
Button{}
/* using a mix of gumbo and halo components */
Button.mx{} /* halo button */
Button{} /* gumbo button */
/* using pure mx components, so still works and is backwards compatible */
Button{}
And of course, supplying your own styleName on gumbo or halo components takes precedence
Since, as you say, the rule is that if the component is a *skinnable component* in the new Gumbo architecture, it is prefixed with ‘Fx’, why not prefixing them with ‘Skinnable’? Yes, it’s longer, but Fx is not a meaningful name.
@likn prefixing the Halo components with Mx wouldn’t be a plausible solution, since one of the goals of Flex 4 is to maintain backwards compatibility.
Would you really want to point your compiler to the Flex 4 SDK and have your entire application be broken?
It seems to me that points 2 and 3 are fairly easily get-around-able.
What’s wrong with the concept that the Gumbo components and Halo components are in separate packages and separate namespaces?
For point 3:
Make Gumbo the default namespace/package. So when you type Button in your MXML using the up-to-date xmlns declaration, you get a Gumbo button. But specify the Halo namespace, get a Halo button. That’s what XML namespaces are for. When in AS3, not a problem – different packages. Code completion – I don’t actually understand what’s different between ‘Type Button – choose between Button and FxButton’ and ‘Type Button – choose between mx.components.Button and flex.components.Button’ – it’s stil a two-step decision.
Point 2:
Separate packages. Make it clear that Gumbo is the default – it’s what people are expected to be working with. Mark Halo components as deprecated when a Gumbo equivalent exists.
All those suggestions could be neatly handled by something like Flex Builder if you provide a project template of ‘Halo/Legacy’ (i.e. all defaults and namespaces will be for Halo – user must add Gumbo namespaces explicitly) and a project template of ‘Gumbo’ (all defaults and namespaces will be for Gumbo).
As for point 1 – namespacing – I think that’s an inherent lack in Flex’s CSS support _anyway_, which needs addressing. If I create a net.mydomain.Button class and want to skin it, currently I’ve got real problems.
Yes, the dot syntax is an issue in CSS; but I’m sure alternatives can be dreamt up. Escaping the names, for example, which is something Flex _already_ does for style properties with odd characters in them.
So:
“net.mydomain.Button”:
{
Some stuff.
}
As for the huge amount of code needed to do that – really? Having ploughed through the styles source code in the Flex 3 SDK, it doesn’t look that bad to me.
The Fx prefix really does feel like a wrong answer that will come back to bite later on – when the _next_ transition between sets of classes happens. Using namespaces/packages/prefixes effectively futureproofs you, and makes it easy for tools to disambiguate. They’re great advantages of the technologies you’ve chosen – features specifically put into those technologies to deal with this sort of situation. I’m disappointed you’ve decided not to use them.
Forgive my CSS failure.
I meant to say:
“net.mydomain.Button” {
fontSize:10px;
}
or whatever. No idea where that stray colon came from.
I don’t like fx prefixing either. Eventually, we will get with a lot of fx components and no “clean-named” components since Hallo components are going away. Let’s better discuss how to make Halo and Gumbo components “selectable” using CSS namespaces. It may cumbersome while Hallo components are around, but once they finally leave the show, we could still preserve our “clean-named” Gumbo components.
I am not sure how this adding a prefix fits into your overall strategy of future releases. It was a good idea to keep it separated by name spaces. Also the separate namespaces makes much more sense when down the road Flex team plans to deprecate halo. So thumbs down for prefixing a set of classes from Gumbo with “Fx” and leaving new classes out. I hope this gets resolved.
I guess am a bit late in joining the party, but I have a bad feeling about the prefix as well. when halo is eventually out, this prefix will make no sense anymore. And every skinnable component tag will require developers to type 2 additional chars before the code complete intellisense makes any sense about what the user is typing. This prefix fix makes me feel that u r solving the wrong problem..
I agree with GVdP. It makes more sense to use “Skinnable” as a prefix instead of “Fx”
I hope this will be done.
From what Deepa said in her addendum I’m beginning to feel that the issues are arising from the lack (at least initially) of parity between the Halo and Gumbo components. So my rather elegant solution is to not release the product until there is a Gumbo component for every existing Halo component.
Simple eh!?
Or is the idea with the Gumbo components to deprecate some of the current Halo components methods and properties?
???????!
-1 for the dual naming as well. I’d prefer to see a Gumbo component replace each Halo component. Lord knows we don’t need five different button implementations, which is what we’ll eventually end up with. They should be polymorphic and backwards compatible wherever possible.
Also, why no FxLabel? Would seem the easiest one of all to implement…
-1 for the prefix…
A temporary solution to the CSS issue could be:
– create new gumbo classes in a different namespace (fx:)
– leave the CSS engine as is
– create a subclass (e.g. FxButton) that simply extends flex.components.Button
This way, when (and only when) mixing halo/gumbo AND css skinning is required, developers can use the Fx version (at least until a better CSS compiler will be ready).
Not that the CSS lacks of namespace support is currently an issue on its own…
So
I agree with Deepa when she explain about the way to maping things in Flex.
The problem of most developers that follow the three in the end are that “not agreeness”.
Keep in mind that 2004 Flex was as2.0 and had a very complicated thing.
The design in mid the marshall plan for Flex 4 is a lot challenge in 18 months to face off.
Imagine to map and support previous version of a SDK that is used for generic propouse with less key enter in less time?
Excuse people But, the way FX prefix is done you will decide if your project decides to target to Flex 4 SDK or flex 2/3.
If you’re using the way flex 2/3 are why not using Degrafa? (www.degrafa.org) That’s the way Adobe Flex Team is working with them.
The only problem I see in the view of Deepa, is like Josh Tynjala says:
“…In short, I’d very much prefer to see the mx: stick around for Halo. It’s already a part of life now, so we’re used to it, and once it’s fully deprecated, Gumbo won’t make my files look like they’ve been infected with a nasty Fx disease….”
Should be a little simple and removing the fx prefix for halo, define the target sdk in namespace and keep using mx.
Looks like more Flex Builder limitations than in SDK as well.
Regards
Igor Costa
This conversation is focused in the outcome of the issue, instead of its root. By admission, Flex 4 is more concerned with extending support for design tools (think Thermo) than the performance of the framework itself. From a developer’s perspective, this is of course a flawed approach. I believe that the performance of a program is far more valuable to the end user, than graphics alone. And lets face it, Flex and the flash player have a lot of room for improvement in the performance arena.
Adobe is a design company, and good design is a valuable asset to any application. I understand this, and from a business viewpoint, there is probably ground to be gained by Flex when it comes to the integration of designers. But in this case, the ends don’t justify the means.
Many adopters of Flex, are small businesses, which do not have a designer on staff. Making the framework inconsistent only makes the life of the developer more complicated and not worth the effort. Please take a look at the bigger picture, and further evaluate what the priorities of the framework should be. By far, I’m only excited about typed arrays, otherwise I see no compelling reason to adopt the new sdk.