I'm please to say I was invited to join the Flex SDK Community Committee, where you can find some of the best known figures in the Flex community like Ben Clinkinbeard, Tink and Doug McCune.
Together we represent some of the most visible Flex users and companies, including such names as Universal Mind and Effective UI.
Our mission is to help make a better Flex SDK, as we say on the above URL: "We represent the Flex community by proposing concrete and actionable recommendations for Adobe's consideration, we coordinate community participation in bug voting and patch submissions, and we advocate the adoption of finalized SDK features to the community at large."
Our first task is to present a single statement to Adobe, as a response to their decision to reopen debate about putting 'Fx' in front of lots of the Flex 4 classes.
You can find a work in progress of our resolution recommendation page here but I want to list out why I think it's a bad idea to have an FxButton (and FxList, and Fx....).
My first thought was that will lead to more confusion - esp. if Flex 5 comes along with 'JzButton' - this will make it hard to pick up Flex, because all these slightly different sorts of button will have different ways of working, and you'll, as a new starter, have to figure all that out. Rather than just using fx:Button, where 'fx' is an xmlns at the top of the file, just like 'mx' is now.If you want to make 'fx' the default name space, you can do that too, and just write <Button> like you do under Flex 3.
As fellow Committee member Tink outlines in the thread linked above, almost everything else boils down to a few tweaks in tooling (Flex Builder) and documentation (asdoc) which are both getting new revisions anyway.
The updated CSS support in Flex 4 will also solve a lot of the 'am I styling a Flex 4 or Flex 3 control' issues.
Very well put. I hope they
Fx resolution
Why we need to use the FX prefix naming convention ?
I agree
I'm not an insider to the
"Adobes decision to allow
"Adobes decision to allow Spark and Halo components co-exist in the mxml"
I don't think this was solely a business thing - not all Flex 3 components are going to be directly translated to the Flex 4 framework (at least, not by Adobe...). There may also be people with externally supplied binary Flex 3 .swc's, no source code, and an external supplier who is unable or unwilling to recompile.
Tom