Fx prefix revisited

Thanks, Peter, for summing up the points to make and asking specific questions.<br /><br />I admit I was so used to the mx: namespace that I was caught in surprise when a Flex specific default namespace was announced to be abolished altogether in Gumbo in the first place.<br /><br />I guess I liked the mx: namespace because it made MXML so much of a recognizable flavor of XML.<br /><br />That said, I wouldn't mind any form of namespace, as long as the underlying language and components remained consistent and true to its conventions and maxims.<br /><br />I'm all fine with three separate namespaces for language, Spark, and Halo components.<br /><br />For the sake of simplicity and grasp-ability, I'd always prefer the most up to date language elements and components to live in the default namespace (http://ns.adobe.com/mxml/2009).<br /><br />I understand much of the current situation and discussion as an effort to find the best way to shell out an intermediate version of the new Flex framework due to the fixed time frame determined by the upcoming release of Flex 4.<br /><br />Language & namespaces<br />=====================<br /><br />At this point in time, I think the problem boils down to the question whether or not the language namespace package and component sets are ready, so I actually have three answers to the question about namespaces:<br /><br />1. new MXML language is complete, Spark component set isn't<br /><br />If the new MXML is ready, I'd like to have it in the default namespace (e.g. <Tagname>). I know that the Spark components won't be complete in time for the Flex 4 release, so I'd put them in a separate namespace (e.g. <fx:Tagname>). And all components from the Halo set which have to fill in for the not-yet-ready Spark components should live in a third namespace (good ol' <mx:Tagname>)<br /><br />2. new MXML language and Spark component set are both incomplete<br /><br />In this case, the Halo package represents the last fully functional language package and should thus be treated as the default namespace (<mx:Tagname> for the sake of consistency)--along with the Halo components. Everything already functional from the new language/component set generation should live in another namespace (e.g. <fx:Tagname>)--as long as the new language isn't ready yet, I think its elements should be treated as additions.<br />This feels like the point we're right now (and will be at the time of the Flex 4 release).<br /><br />3. both new MXML language and Spark component set are complete<br /><br />This will be some time post-Flex-4.<br />Here the new MXML language and Spark component set together form the most up-to-date set and thus should live in the default namespace (I actually don't care whether that'll be <Tagname> or <fx:Tagname>). No need for any other namespace unless a developer deliberately chooses to include one, e.g. for the sake of using Halo components or 2006 language elements.<br /><br />I think we should aim at step 3 and always try to have one consistent language package for the most recent complete language/component set, adding all the rest in separate namespaces, as we all out here community do it all the time with our own and third party packages and frameworks.<br /><br />CSS<br />===<br /><br />I'd favor one of the pillar of the CSS standard itself--cascading--when it comes to addressing specific elements with styles.<br /><br />If we have components in different namespaces with clashing names, I still don't see the point why we can't have two different &lt;Style> tags, too--one for every namespace.<br /><br />If I want to address all, say, <Tagname> elements (regardless of the namespace they're in), I'll only use one &lt;Style> tag--that one of the default namespace.<br /><br />If I want to make a distinction between components in different namespaces, I'll define "Tagname {}" in &lt;Style> and another "Tagname {}" in <mx:Style>, for example. This way, style definitions can live neatly alongside each other without any interference or clashing. That's what namespaces in XML are for in the first place, and I don't see why styles in Flex should contradict this principle in all cases.<br /><br />Incorporating all styles into one &lt;Style> tag feels merely like a decision of convenience, not language (and XML principle) consistency. I can live with and like convenience decisions as long as they don't get in the way of a clear and consistent language.

OK, since we've been told there'll be a decision by the end of the week, I'd like to get my thoughts in :)<br /><br />If it were my decision:<br /><br />1) Separate XML namespaces (of course) - use a prefix for Halo because we're used to it, no prefix for Spark coz it's prettier. We can have prefix-less attributes on prefixed elements and still have it be viable XML. Since the "XSDs" change based on compiled libraries, it's never going to fully validate properly anyway, so who cares? I mean xml namespace prefixes, ie <mx:Foo/> and <SparkComponent/> not class or element name prefixes.<br /><br />2) Allow fully qualified classnames in CSS, and assign them higher priority, ie "mx.controls.Button" outweighs "Button"<br /><br />3) Move the CSS warnings from the compiler to an optional flag. They're annoying as hell, and Builder likes to use them to litter your (valid) MXML code with CSS warnings. Or make the warning system smarter. Either way, it's one-off compiler work that doesn't make life difficult for users.<br /><br />4) Worst case, use only one namespace, and alias halo components to things like "MxButton". It'll remind everybody of the work that needs doing.<br /><br />5) If the SDK team @ Adobe can't get all the gumbo components done for 4.0, *outsource those that don't make the cut to us!* Document the needs, document best practices, and rotate a "community component verifcation sucker" around the team every week / day. Maybe we get them built in time, maybe we don't. But everybody wins.<br /><br />6) *also* add FxFoo component mappings to the manifest for the Halo namespace, so people can add some Gumbo components to their old code without changing anything at all, so long as they compile against 4.<br /><br /></rant>

I am amazed this debate ever started.
MXML is based on XML which has decent namespace support.
Actionscript 3 is a OOP language with package and namespace support.
Why oh why did anyone ever imagine that component prefixes should be used?! It just shows a lack of understanding.
Adobe really should be listening to the very vocal voices on this subject, learn and then do away with this non-sence idea of prefixes.

Hi all, hearing your feedback is great and I hope we can approach a decision for Gumbo soon.

First, a minor point: for the default set of namespaces in MXML - hearing folks are used to namespace prefixes is useful. Prior to this I had the sense that prefix-less MXML was where folks wanted to go - though personally I don't mind either way. As others have said, MXML is XML and the only reason we're discussing this is that a convention has to be established for documentation.

Point 1.) If people prefer prefixes, we establish the convention that prefixes will be used for our well known MXML namespaces (for the sake of consistency).

For the namespaces themselves (ignoring CSS issues for now), I'm hearing loud and clear that folks are used to multiple namespaces because custom components and third party libraries are the norm. First, I think it's worth repeating the following assumption:

Point 2.) Flex 3 MXML 2006 namespaced documents will still be recognized by the Gumbo compiler.

Given that, some folks have explicitly said they are fine with Gumbo separating MXML 2009 into 3 well known namespaces. Others alluded that they were fine with "multiple namespaces" but didn't describe what they thought would live in each namespace.

I'd like to hear from the folks who weren't specific about what they think of the original proposal for three well known namespaces: specifically, a new MXML 2009 namespace (language), a new Halo namespace (component) and a new Spark namespace (component). The contents of these namespaces are largely distinct (though faceless components (like services) would exist in halo and spark). MXML 2006 would not be mixed with MXML 2009.

Since folks said they're comfortable with multiple namespaces, are they also comfortable with having to re-namespace and potentially re-prefix Flex 3 content when they want to mix it into a Gumbo document? Is it obvious what would be a Spark component, a language component, a Halo component?

The concept of merging namespaces was also brought up in the original proposal, but it seems people are fine with just a clean separation of components and the language. Does anyone object to leaving them separate? Or were some people assuming there would be some default merging, say of at least spark + faceless components into MXML 2009? I'd like us to be specific about people expect in each namespace and what the day-to-day MXML experience would be like.

To me, arbitrary merging of namespaces bringing back the issue of collisions and I feel that it makes sharing code more complicated as you have to consider the existing merges that have been applied.

Perhaps less important to some, I also want to circle back on the issue of CSS type selector collisions. I heard the following:

a). Disambiguation of CSS type selectors is less urgent as basic type selectors are not the usual approach for customizing component styles.
b). There's an acceptance of having to consider namespaces in CSS selectors if types needed to be disambiguated.
c). Jared also mentioned the possibility of ignoring unknown style properties.

Hearing a) is a good reminder, though I think we still need to decide on the approach in the Gumbo timeframe - even for edge cases. For b), I'd like to dig deeper: while there's an acceptance of having to use namespaces if and when CSS type selectors need disambiguation, I haven't heard people's opinions if this was made mandatory for all type selectors. Also, I think c) is an easy way out, but the issue of missing style property typos is likely a deal breaker.

Thoughts?

Most of my applications use multiple libraries from open source to just libraries with different namespaces used across multiple projects. I would agree with Ben C. and Andrew W. on the frequency of multiple namespaces and it being something very common outside basic applications.

To me, the SDK should always do things the "right" way. We (Adobe) should expect developers who are savvy enough to grab the SDK and use the command line to be able to work around and comprehend things like namespaces. What we should focus on is making the tool sophisticated enough to abstract some of the more complex issues like this one.

This is essentially the way .NET does it as far as I can tell. There are some sophisticated aspects of the .NET framework that are extremely tedious to code by hand but that Visual Studio makes really, really easy. And it's resulted in the fact that coding .NET without Visual Studio is almost unheard of.

From a revenue standpoint this is exactly what I'd like to see happen with Flex Builder. We've got an open source, elegant framework and a tool on top of it that is very easy for new developers to pick up and takes away some of the complexity behind parts of the framework. As developers using the tool get more used to the SDK, they can break away and dig deeper, but the tool ultimately becomes the entry point for everyone which leaves the SDK team free to make development choices based on what's good for the framework as opposed to what's easier for the tools.

=Ryan
ryan@adobe.com

I think the Fx Prefix is optimizing the solution at the for the wrong point in time and looks like a hack from every direction to the outside world. I dont understand the fear of namespaces that people have. Namespaces/Packages were implemented to group like classes, reduce confusion and avoid naming collisions and they work. There will be a day that every single Halo component will be obsolete and having some legacy of the transition hang around forever will only make Flex look as confusing to a new user as AWT and Swing in the Java world. <br /><br />b Number of Namespaces: <br />I have 3-6 namespaces in my average custom component and almost always at least 2 (I am a big fan of code behind) and I think it is one of the greatest benefits of MXML. Ive also experienced having two components with the same class name in two different packages in a project. Who hasnt built a custom component only to find it later in flexlib or some other library done slightly differently or better and then had them coexist in the same project until you can sort them out. Ive never had trouble telling them apart and Ive never used two mixed two classes with the same name in the same component or class. Flex builder even declares namespaces for you if you havent done so already when you add a new component/control so it is near zero effort (it is not like I am typing xmlns all the time).<br /><br />b Mixed Usage:<br />The only argument for mixing <mx:Button /> and <fx:Button /> in the same MXML file or Actionscript class is perhaps if you built a really complex app/compoonent in a single file. If you did such a thing youd have readability problems no matter what the classes were named. Youd also be violating tried and true OO practices along the way. For the average developer, if youre class is longer then a screen or two then odds are youre violating an OO principle somewhere. At minimum you should not optimize the plan for this case.<br /><br />b Code Completion: <br />Although I havent been the best about removing outdated code from everywhere in my projects, Ive at least gone back and added [ExcludeClass] to all of my deprecated shared classes so I only ever see the latest and greatest in code complete. I dont want to be using older less maintainable code ever again; I might not be able to go back two years in project X and rip it out but I can at least avoid compounding the the problem. There are reasons for the creating the new components and encouraging the use of older ones just makes it easier to write potentially buggy code. If Im maintaining a Flex 3 app then that is already in my project properties somewhere and then it would be nice to see the what is relevant to Flex 3. mx:Button just isnt relevant to a brand new project in flex 4. mx:Button is isnt relevant to a new developer after Flex 4 ships and isnt going to maintain someone elses old code.<br /><br />b Searching Documentation: <br />Personally Im in the habit of typing mx.controls.Button when then I search the API documentation. It lets me skip the overview docs and go straight to the class reference where I really want to be anyway. Id personally just switch to typing fx.controls.Button or what ever once Im looking for the Fx version. Honestly, mx:Button is essentially deprecated with flex 4 so I dont want to see it unless Im putting in extra effort to type it out. If the new button isnt better then the old one then there is no point in creating new one in the first place.<br /><br />b CSS Selector Collision Issue: <br />Using the top level CSS selectors such as Button has always seemed a bit risky to me. Sorry the use of the Button CSS selector is like using a global variable you took the risk. What if I need another type of button then I might be undoing things Ive done somewhere else and I now have to look at two places for what my component actually looks like. Although the language gives you the option to do something it doesnt means it is smart to take advantage of it. sytleName= may littler my code but I can change styles out without fear of breaking my app. I wouldnt mind having to add some sort of namespace to reduce confusion but if your using Button youve already created a readability problem with the potential having to look in two places define a style. I'd vote apply the style to both Buttons and fail silently or a produce a warning if one of the properties didn't exist.<br /><br />b JavaFx as an example of how to go wrong: <br />The pre-release versions of JavaFX had the problem of two different types of nodes (essentially wraps of AWT and Swing components) and it tried to hide that fact from the developer. They didnt play nice with each other but they tried to make it so you could use both at the same time with little or no effort. It was messy, it was confusing and it was buggy. They lost a potential developer and they had to do a major rewrite from pre-release to 1.0 and I havent looked back because of my bad experience.<br /><br />b New Users:<br />If Im new to a framework or a language I dont ever want to be encouraged to use outdated/deprecated code. I want to be using the latest and greatest that is here and supported for the long haul. I'd prefer that one day reading an outdated tutorial I see an <mx:Button and have to research it not have it in my face day one.<br /><br />b Most Common Controls I use:<br />Button, Label, VBox, HBox, Canvas, List, TileList, AdvancedDataGrid, Image + tons of custom controls. I would never mix types in the same component and most the others are a once in a app thing.<br /><br />Ive been using Flex for at least the last two years and Id say FxButton makes me want to evaluate Silverlight or JavaFx again. If Flex is ever to get past the Flash is just for widgets and animations reputation that it has sometimes then what appears to be a hack can mean a lot. Regardless of your reasons, the Fx prefix looks bad to anyone not reading a 100 page book describing why you did it.<br /><br />edit: formatting

@Matt: I understand that it is not reasonable to expect developers to adopt Spark entirely over Halo, given the timelines. I can see the case for a Flex 4 application using a Spark List with a Halo DataGrid. But is it also expected to be common to see a Spark List alongside a Halo List? I think the usability concerns about ActionScript might be overrated.

What you're doing here is you're "polluting" the MXML language namespace with a bunch of new tags that start with "Fx". One of the first questions a beginner is going to ask is, "What is this FxButton, and how is it different from Button?" And the answer's going to be, "Oh, uh, don't worry ... I'll explain that later." If your goal is to make Flex easier to adopt for HTML developers and the like, I don't think this is helping the cause. The beauty of MXML is its simplicity: everything is called exactly what it is. A button is called a Button, and check box is called a CheckBox, an application is called an Application, and so on. That simplicity is really what attracts developers to Flex in the first place. It makes a statement. Having tags like 'FxButton' might make the language look more sophisticated, but in the end it's going to make it seem harder to adopt for newbies.

By the time you reach Flex 5 or Flex 6, you should have one prevailing component set, so from a long-term perspective I don't think it's a good idea to go for the 'Fx' prefixes now.

I do like the general idea of separating out the core language from the component library.

Like I said earlier, I obviously don't understand the full picture (with respect to the IDE, etc.), so please take this as my humble input. I feel strongly that by introducing a bunch of new tags with 'Fx' prefixes you are corrupting the simple and easy-to-learn MXML language that we have all known and loved for years.

$0.02

My 2-cents vote goes to multiple namespaces. In most of my projects, I already have namespaces for Degrafa, Flexlib, Birdeye's RAvis, Nitro-LM, etc... so what's one more? Namespaces are something we should encourage new developers to learn, not hide them from their apparent complexities.

The power of Flex comes from being able to take a pinch of this and a bit of that from various component libraries out there and mashing them all together to get the desired result. Halo is just ONE of them, and Spark will still just be ONE of them. They're not the center of the universe. For example, in one of my projects, I'm using ObjectHandles (http://code.google.com/p/flex-object-handles/) not as a resizable/rotatable container for images as intended, but rather as a new-fangled horizontal menu where each sub-menu can be resized. I'm mixing in ObjectHandles, mx:List, and Degrafa to get this result.

It's not uncommon to list 5 different open-source licenses on my Help->About window to cover the various components used in a project.

I mostly use Text, TextInput, TextArea, Combobox, DataGrid and Image...mostly. And in 9 out of 10 projects I have custom components.

Speaking of parity, how hard would it be to convert the Halo DataGrid to a Spark DataGrid with the current halo feature set? I mean I think of the list of Spark controls not on the Flex 4 list, DataGrid has to be the hardest to convert but after that shouldn't the remaining controls be easy? I can help out. I'll convert the Spacer component (that's a joke - look at Spacer.as). I suppose it's not an option to delay Flex 4 to convert the remaining components to Spark? Spark components are mostly just the UI Controls not Containers right or do the containers have skins too?

I know you are trying to go easy on new developers but I mean they have to be pretty smart to be in this field. I think they would pick it up.

BTW What will the Flex Builder Component panel look like with 2 namespaces in it? If it has Spark "Controls" folder and a Halo "Controls" folder then when they add a Spark component to the stage won't that automatically add the namespace? What if the idea of namespaces were more prominent? Like in the New Project dialog you inform developers that there are 2 component sets and they can choose one or the other by the namespace (and add a click here for more details on what the heck we're talking about type of thing).