Fx prefix revisited

To answer this question, I usually only use about a dozen or so controls per project with regularity. CombBox, Data Grid, Button, Panel, Sliders, ControlBars, ButtonBars....<br /><br />Other than that its as Ben mentioned varies from project to project and usually just once.<br /><br />As for as name spaces, the last project I did was a medium size one that used Caringorm. That had 3 or so namespaces besides the mx namespace that is. I always had the impression that when a developer made numerous custom components in a project, she created custom namespaces to keep track of them.<br /><br />Maybe its just how I learned Flex, but I assumed others used custom namespaces frequently.<br /><br />Alan<br /><br />"Matt Chotin" <member@adobeforums.com> wrote:<br /><br />Maybe to understand the likelihood of the component namespaces being mixed itd be helpful for folks to go through their apps and see what Flex controls they actually use (and their frequency).

I'm not really sure how to best gather a list of the components used as I think it varies pretty widely depending on the type of project. That being said, I think its the wrong question to ask. I (and many others I've talked to) disagree that multiple namespaces is a problem, even for beginners.

I just did a quick search of my current project and the one prior to see how many MXML files contain only one namespace and the result is well below 10%. Searching for the string 'xmlns' shows that the average number of namespaces per MXML file is between 3 and 4.

I just don't get all the effort to avoid multiple namespaces when they are simply a fact of life in Flex and completely inevitable outside of Hello World.

Maybe to understand the likelihood of the component namespaces being mixed it’d be helpful for folks to go through their apps and see what Flex controls they actually use (and their frequency).  It’s a non-starter at this point to argue that we should spend time bringing Spark up to functional parity with Halo (where even if there isn’t a 1:1 mapping of Spark to Halo controls you have enough to do everything).  As you (Manish) have pointed out, Adobe’s in business and therefore time-to-market is something we take very seriously, and that influenced the decision to mix the components and not go for functional parity in our first release.  For example, there will not be a Spark DataGrid in Flex 4.  



But maybe our assumptions as to how much of Halo you’ll need is wrong.  If you guys can spend some time gathering a list of the components you use maybe it will shed some light on how big an issue this is really going to be.



Matt





On 2/8/09 11:58 AM, "Manish Jethani" < member@adobeforums.com> wrote:

A new message was posted by Manish Jethani in



Developers --

  Fx prefix revisited



I'll throw in my two cents as well.



First of all, if mixing components from Halo and Spark is indeed going to be a common use case for Flex 4 (as Matt seems to suggest in #5), then all bets are off: It'll be hard to write and maintain ActionScript code that has to deal with two different types of 'Button' objects in the same context. So, by all means, if the intent is to encourage developers to mix components from Halo and Spark, then the new Spark components should be given different names -- the 'Fx' prefix.



It's hard for me to imagine why this would be the case though. I for one wouldn't want to use two different types of buttons in the same project -- even if they have different names (Button and FxButton). I would want to migrate my entire project over to Spark or just leave that one at Halo. I don't think there can be a good argument for only partially adopting Spark in a project. Maybe I'm wrong.



I believe Adobe should work to bring the new com! ponent set to some level of parity with the old one and then just encourage developers to use one or the other.



Secondly, there's the goal of MXML source compatibility: that you should be able to migrate your Flex 3 application to Flex 4 with little or no changes to your MXML source. Is this really a goal? I think it should be. And if it is, then replacing the Halo components in the MXML language namespace with the new Spark components is going to be a disaster. Suddenly the old properties won't work, the code won't even compile without a lot of changes, and so on.



So here's my proposal:



 1.  The old Halo components should continue to be part of the MXML language namespace for backwards compatibility. This also maps nicely to their AS packaging (mx.controls.*).



 2.  The new Spark components should be in their own namespace.



 3.  The Flex Builder IDE should filter out the Halo components from the MXML language namespace during code com! pletion. (i.e. if you type "mx:" it shouldn't list "mx:Button"! as one of the options.)



 4.  The Halo components should _also_ be available through a separate 'Halo' namespace. Use of this namespace should be encouraged when using Halo components.



 5.  Both Flex Builder and the API docs should find a way to distinguish between the two component sets when listing them in the panel/sidebar.



 6.  CSS needn't have support for namespaces right now. It can just apply the styles in a certain order: first try to match a Halo component, then a Spark component. In the future, when CSS does have support for namespaces, this rule of precendence would still apply.



About points #3 and #4, the idea is that the choice of using one or the other (or both!) component set should be made at the project level. Once a developer has chosen to use the new Spark components, the Halo components should get out of the way -- and vice versa. This could be a project setting. Again, I'm not a big Flex Builder user, so I'm not really qualified t! o talk about this.



I do think that the use case of mixing Halo and Spark components is overrated.



The obvious problem with my proposal is that even the simplest hello-world app would require two namespaces:



  <mx:Application xmlns:mx="..." xmlns:fx="...">

    <fx:Label text="Hello, world!" />

  </mx:Application>



Personally I think that's still better than the current 'Fx' option:



  <mx:Application xmlns:mx="..." xmlns="...">

    <FxLabel text="Hello, world!" />

  </mx:Application>



That is to say, learnability-wise, the former is still better than the latter. Both make use of two namespaces, only the first one is elegant while the second one looks like a hack.



I'm sure there's a lot of thinking and planning and consideration that goes into this, but it's good for us to be able to offer our opinions here. So, thanks!

---

View/reply at Fx prefix revisited < http://www.adobeforums.com/webx?13@@.59b7cdf0/18>

Replies by email are OK.

Use the unsubscribe < http://www.adobeforums.com/webx?280@@.59b7cdf0!folder=.3c060fa3>  form to cancel your email subscription.

I'll throw in my two cents as well.

First of all, if mixing components from Halo and Spark is indeed going to be a common use case for Flex 4 (as Matt seems to suggest in #5), then all bets are off: It'll be hard to write and maintain ActionScript code that has to deal with two different types of 'Button' objects in the same context. So, by all means, if the intent is to encourage developers to mix components from Halo and Spark, then the new Spark components should be given different names -- the 'Fx' prefix.

It's hard for me to imagine why this would be the case though. I for one wouldn't want to use two different types of buttons in the same project -- even if they have different names (Button and FxButton). I would want to migrate my entire project over to Spark or just leave that one at Halo. I don't think there can be a good argument for only partially adopting Spark in a project. Maybe I'm wrong.

I believe Adobe should work to bring the new component set to some level of parity with the old one and then just encourage developers to use one or the other.

Secondly, there's the goal of MXML source compatibility: that you should be able to migrate your Flex 3 application to Flex 4 with little or no changes to your MXML source. Is this really a goal? I think it should be. And if it is, then replacing the Halo components in the MXML language namespace with the new Spark components is going to be a disaster. Suddenly the old properties won't work, the code won't even compile without a lot of changes, and so on.

So here's my proposal:

1. The old Halo components should continue to be part of the MXML language namespace for backwards compatibility. This also maps nicely to their AS packaging (mx.controls.*).

2. The new Spark components should be in their own namespace.

3. The Flex Builder IDE should filter out the Halo components from the MXML language namespace during code completion. (i.e. if you type "mx:" it shouldn't list "mx:Button" as one of the options.)

4. The Halo components should _also_ be available through a separate 'Halo' namespace. Use of this namespace should be encouraged when using Halo components.

5. Both Flex Builder and the API docs should find a way to distinguish between the two component sets when listing them in the panel/sidebar.

6. CSS needn't have support for namespaces right now. It can just apply the styles in a certain order: first try to match a Halo component, then a Spark component. In the future, when CSS does have support for namespaces, this rule of precendence would still apply.

About points #3 and #4, the idea is that the choice of using one or the other (or both!) component set should be made at the project level. Once a developer has chosen to use the new Spark components, the Halo components should get out of the way -- and vice versa. This could be a project setting. Again, I'm not a big Flex Builder user, so I'm not really qualified to talk about this.

I do think that the use case of mixing Halo and Spark components is overrated.

The obvious problem with my proposal is that even the simplest hello-world app would require two namespaces:





Personally I think that's still better than the current 'Fx' option:





That is to say, learnability-wise, the former is still better than the latter. Both make use of two namespaces, only the first one is elegant while the second one looks like a hack.

I'm sure there's a lot of thinking and planning and consideration that goes into this, but it's good for us to be able to offer our opinions here. So, thanks!

> ActionScript

I can accept that there will be projects that deal with legacy code and need to address classes from different versions that share names. I don't, however, see why anyone would ever have the need or desire to instantiate both versions of a class in the same container class, which is the only way this is a problem. If you're writing new code, why would you use an old version? If you did need to use the old version for some reason, why would you mix in the new version? Spark components will be nice but they don't make you taller or better looking. If you really feel the need to mix (again, I cannot think of ANY reason why this would be necessary or desired) then you have to put up with FQCN.

As far as knowing which package the class came from, in FlexBuilder all that is required is mousing over to get the FQN.

> ASDoc

The very first item on every class's ASDoc page is Package. Just below that is its inheritance chain and interfaces which I assume would be different between versions. If you want to further distinguish put an icon in each page's header. As the saying goes, make it idiot proof and someone will build a better idiot. Trying to guard against people who can't pay enough attention to read the right documentation seems like a pretty drastic lowering of the bar.

> Namespaces

When I first started learning Flex I literally had zero knowledge of namespaces. I will also admit that complex namespace structures like SOAP still trip me up from time to time. That being said, seeing and using namespaces in MXML made sense long before I even realized that's what they were. It immediately clicked the first time I instantiated a custom component and FlexBuilder created and assigned the namespace for me. I think I barely even noticed the mx namespace, probably because I had seen (but not used) ASP.NET code before.

I’m not gonna respond to everything since it’s the weekend, but just a few things.



We’re spending a lot of time talking about reading code in MXML, but we’re also worried about ActionScript.  We’re now likely to have more classes that would need to be fully qualified in code or you’ll need to make sure that your imports never use *.  It’s also harder to backtrack when reading source to see which package a class came from.  More of an issue for larger codebases, than smaller, but something to consider.



For the ASDoc overlap you guys mention HTTPService, but that class and the dupe involve superclass/subclass and are basically the same.  In the Spark/Halo case they’re going to be very different classes.  In the service case you’ll basically see the right APIs regardless of which one you look at, whereas you could really be wrong if you click on the wrong one in the component case.



All of you guys for the most part are experienced Flex developers at this point, and I know the multiple namespaces doesn’t scare you at all.  We however definitely remember as Flex came out a ton of confusion over how namespaces worked, what they meant, and how to use them.  I’m very concerned about new users being able to pick up how the system works, hence our proposals for merging namespaces as much as possible.  Do you guys have experience working with people who are new to Flex and maybe not XML experts?  E.g., folks coming from the world of HTML?  Remember, we’re always trying to lower the bar to becoming a good Flex developer, so while lots of namespaces might appear clean from a design standpoint, is it actually easy to learn?



Matt





On 2/6/09 6:05 PM, "Ben Clinkinbeard" < member@adobeforums.com> wrote:

A new message was posted by Ben Clinkinbeard in



Developers --

  Fx prefix revisited



I agree 100% with Simeon's comments.



I think namespace support in CSS would be great and would love to see it happen at some point, but I really don't think it needs to be in place immediately or in order to avoid the prefixes. styleName and the silent failure point Simeon raised make CSS a complete non-issue in the short term. If you add CSS namespaces later great, its a new feature to tout. If not, no big deal.



I also agree that separating the language namespace from component set namespaces is the most logical, clean, forward compatible and consistent approach available. Its how we use our own components today, so what could be more natural?



Tink also raised several valid points that overlapping class names in Spark wouldn't raise any issues that are not already present with HTTPService and the other duplicate class names.

---

View/reply at Fx prefix revisited < http://www.adobeforums.com/webx?13@@.59b7cdf0/14>

Replies by email are OK.

Use the unsubscribe < http://www.adobeforums.com/webx?280@@.59b7cdf0!folder=.3c060fa3>  form to cancel your email subscription.

I think Tinc covered everything I wanted to say.

People are used to using
xmlns="....... xmlns:mx="....... xmlns:externalComponent=".......
saying that if they want to use Flex 4 components they need either change the default to a new URL or add xmlns:fx="...... isn't as big a deal as I get the impression Adobe thinks it is.
Flex Builder is quite capable of hiding a lot of that anyway, esp. for new build Flex 4 projects.

AsDoc already has to copy with AIR-only classes, so marking Flex 3/4 ones is obvious enough.

I don't think anyone is going to be confused if new components are added to the (a) Flex 4 namespace, as long as they're all in the Spark style.
*If* Flex 5 has another new component architecture, then adding a new new namespace seems to me to be clearer than introducing JzButton (or ButtonJz though I think that is confusing).

I agree 100% with Simeon's comments.

I think namespace support in CSS would be great and would love to see it happen at some point, but I really don't think it needs to be in place immediately or in order to avoid the prefixes. styleName and the silent failure point Simeon raised make CSS a complete non-issue in the short term. If you add CSS namespaces later great, its a new feature to tout. If not, no big deal.

I also agree that separating the language namespace from component set namespaces is the most logical, clean, forward compatible and consistent approach available. Its how we use our own components today, so what could be more natural?

Tink also raised several valid points that overlapping class names in Spark wouldn't raise any issues that are not already present with HTTPService and the other duplicate class names.

BTW All else being equal in a non resolution, placing Fx after the name, "ButtonFx", is better IMO than in front.

My 2cents:
When I saw MXML for the first time it was apparent that the namespace "mx:" was classifying a group. I think that will be understood by new comers right away and I haven't had any new students question it. I don't mind keeping the namespace tags and in fact "<Button>" looks "weaker/cheaper" than "<mx:Button>". I'm not sure if its sentimental or defines depth but I would much rather keep using the namespaces.

I think if I understand correctly I would support Ely's suggestion in setting a default namespace in the Application tag. Everything else can define itself based on that setting. If you set the default to spark then when you use code complete for the button class or control then the fx button will be chosen every time. If the halo namespace is in your project then Flex Builder would list the spark button first and the halo button second in the code complete.

As far as CSS I think if you are setting a default namespace in your application to spark than "Button" would refer to the Spark Button class. It makes sense to me to make the distinction between namespaces using the same syntax as we use in MXML:

Button { color:#00FF00 } // refers to the default namespace (spark or halo)
mx:Button { color:#00FF00 } // refers to the mx namespace

PS I ditto what Tink said. I don't have any problem mixing mx and fx namespaces. It seems clear to me and I'm pretty much a dimwit.
PS Simeon made a good point that if it's CSS the styles that aren't supported will fail and really, if we are setting styles for Spark buttons AND Halo buttons than we can just use classes. I don't see a problem in that as its the recommended method when you have more than one style.

Between Matt's thougts and Tink's thoughts I dont think I really have anything to add. I really think the CSS is a non-issue. I say that because you act like type selectors are the only way to access an element. IF *IF* an application uses button from both halo and gumbo there are other ways to assign css values than just through the type selector. Especially in Flex 4 with the new css additions you are making. Second on the CSS front, the way its currently implemented styles that are not supported by one version or another are just not applied, they fail silently. So with a single comment to seperate the styles you don't need seperate definitions for the css.

On the namespace issue I can not shout loudly enough, that declaring a language and then referencing component libraries is brilliant. When we don't jam all the classes into one manifiest we dont have problems with Button and FxButton. Leave the 2006 namespace the way it is for backwards compatibility, but for 2009 specify the language namespace and then use the library url's to include the component framework that you want. The fact that we as developers use namespaces to include our code for our applications makes the use of namespaces to select a component framework brain dead simple. More namespaces is not a *more* complicated problem, its the right solution for an xml based language.

I feel like on both these fronts we are trying to solve problems that dont really exist.