Announcing the Flex SDK Community Committee, and maybe an end to FxButton

Submitted by Falken on

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.

Sections

Submitted by IanT (not verified) on Wed, 02/11/2009 - 08:49

Permalink

The resolution on that recommendation is excellent - I wholeheartedly approve. Let's hope it gets through. :-)

My thoughts with the FX debate is that xmlns and packages are precisely made not to have to prefix classes with anything. And you will always be able to use or anyway. In the other hand, rare will be the case when you will need Spark and MX components in the same MXML file or AS class. Honestly I can't see any reason why we need to use the FX prefix naming convention.

I agree. XML namespaces and packages are designed exactly for this. The legacy components should only be in the MXML 2006 namespace and not in the MXML 2009 namespace. You should be able to use both by including a different alias for the MXML 2006 namespace in MXML or fully qualifying the components if they're going to be in the same AS class for some reason.

Submitted by Jay (not verified) on Mon, 02/16/2009 - 08:48

Permalink

I'm not an insider to the issue but I believe that at the heart of all this mess is Adobes decision to allow Spark and Halo components co-exist in the mxml file. This can only make sense from a business perspective, but it's bad for user experience. I'm not sure it's on the table, but I wish they'd see the light and reconsider that.

"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