Fx prefix revisited

sorry: double post.

Hello fellow developers,<br /><br />these are the points I consider crucial:<br /><br />- MXML is an XML flavor. XML supports namespaces. If you learn XML, you accept the existence of namespaces--you even appreciate it. So in MXML, namespaces should not be thought of as an alien concept to "new" developers.<br /><br />- Halo-Flex developers are accustomed to the mx: namespace for Flex components.<br /><br />- This is all about transition. We are facing these challenges now (and only now) because we are shifting to a new and better generation of components. Not all Spark (when did we start talking about Spark instead of Gumbo?) components will be ready at the time of Flex 4 rollout, so we need a temporary solution that is easy to grasp, backwards- and forward-compatible, and consistent to core MXML maxims.<br /><br />- future developers will always prefer intuitive naming conventions to naming exceptions. &lt;Button&gt; is more intuitive than <FxButton><br /><br />b With that in mind, I strongly favor Matt's proposal of merging the Spark namespace with the MXML language namespace via flex-config--with the option to customize namespace settings--and putting the Halo components into a separate namespace (I'd suggest using the the good old mx: namespace).<br /><br />i Here are the drawbacks:<br /><br />- the code will look a little messy while we're in transition to the Spark component set (most likely until way after Flex 4)<br /><br />- providing a helpful toolset/IDE/code completion might get a little tricky<br /><br />- documentation will have to differentiate between ActionScript classes (ClassName), Spark (ComponentName) and Halo components (mx:Component)<br /><br />i These are the benefits:<br /><br />- the concept should be quite easy to grasp for novice developers<br /><br />- backwards and forward compatible<br /><br />- we can use the Spark components right away by using the most intuitive, maxim-consistent name, e.g. &lt;Button&gt; (the button seems to be the most common example) instead of <FxButton> (or if one chooses a separate namespace for Spark, by using <fx:Button> or <s:Button>--you name it)<br /><br />- there will be MXML language tags or faceless components without a namespace, clearly indicating to the novice developer that they either belong to Spark or to the core language (and thus, in the latter case, work with either components)<br /><br />- colliding Halo components remain consistent to the naming practice in Flex 3 by using the separate mx: namespace (mixing in mx: components is allowed and even encouraged)<br /><br />- new Spark components can be added painlessly over time, regardless whether there are naming collisions or not<br /><br />- once the Spark components are complete, we can finally do away with the mx: namespace for good; then we'll have a beautiful, new, consistent component set without any naming weirdness, adhering to maxims and naming conventions<br /><br />I want to point out that I know that this is a huge task for the Flex SDK team right now, but I sincerely believe that we would shoot ourselves in the foot if we were to opt for a "works for now" solution instead of an intuitive, maxim-consistent and future-proof concept.<br /><br />Thanks to the Flex SDK team in the first place!<br /><br />Best regards<br />C.

I'd just like to try and address of the problems in the original post, that I don't believe are problems, and if you agree maybe they can be crossed out of the original post and we can concentrate on the real issues.<br /><br />- How will new users understand the differences between Spark and Halo classes, and especially understand when there is overlap<br /><br />They will have different namespaces. <br /><br />- What should documentation do to differentiate between Spark and Halo controls, and how do we control which page a user arrives at when searching <br /><br />Nothing, you don't do anything now with HTTPService and I haven't ever seen a comment about it being a problem, so why should it be a problem in this case. Obviously I will be able to navigate using package names as we currently can if I only want to see the Spark classes.<br /><br />- How will someone reading code easily understand which control the code is using<br /><br />It will have a different namespace. Having Fx at the beginning of the class name won't be any clearer than having a different package.<br /><br />- Given the change in architectures, how does someone easily know which architecture a component belongs to<br /><br />It will have a different namespace.<br /><br />- The number of overlapping controls between Spark and Halo will increase after Flex 4, Spark will receive new controls over time <br /><br />Great, bring us new controls. This a problem?<br /><br />- How does code hinting work when you have overlapping classes (what can it do to help differentiate) <br /><br />Your making out that code hinting knows what we want at the moment which just isn't the case. The examples on this subject that have been given have all used Button. Flex Builder is not able to auto complete Button without the user choosing from a list EVER! Even if I type the whole class name and invoke the code completion FB doesn't know I want a Button and I have to choose from Button, ButtonAsset, ButtonAutomationImpl, ButtonBar, ButtonBarAutomationImpl, ButtonBarButtonSkin, ButtonLabelPlacement, ButtonSkin. So at the moment we are all used to choosing from a list provided by the code completion, and we will all be capable of picking the correct button from the list. If I am honest i would generally probably only type the first 2 letters (i.e. Bu) and get a much bigger list to choose from. If your argument on this point is that you don't want large lists, imagine what it will look like once a load of class are added with the Fx prefix, it'll have list them all, and as you said above you plan to add more after Flex 4.<br /><br />- If a list of components is in a panel, how do those components get differentiated<br /><br />Not sure I understand this one, by their namespaces? If I'm misunderstanding can you clarify this problem please.<br /><br />- Should a tool warn when components from different architectures are mixed, how does the tool know when such mixing of overlapping components or architectures is intentional<br /><br />This has nothing to do with the issue (Fx prefix). Whether you use the Fx prefix or not you will have to address this issue, whether you decide to give and warning and how, isn't affected by the prefix or no prefix.<br /><br />- Should the tool promote one architecture's components over another, or provide user preferences to control promotion, and how flexible do those preferences need to be <br /><br />This has nothing to do with the issue (Fx prefix). I understand this will need addressing like the point above, but it doesn't have anything to do with the Fx prefix, and therefore should be left for another discussion.<br /><br />-------------------------<br /><br />Once some of these points that clutter the real problems are out the way, we would all be in a better position to look at how/if the other issues can be addressed successfully.<br /><br />-------------------------<br /><br />I'd also like to make a point on the following comments<br /><br />"letting customers mix the two language namespaces in the same document feels confusing as all hell. <mx:Script> and <fx:Script> in the same document just doesnt make sense in my mind. ".<br /><br />Thats a bad example right? Your not going introduce a new Script tag are you? Now I can see that there will be a mix of language namespaces in the same documents, but surely this isn't a problem? I think I pretty much always have more than one namespace in my documents.<br /><br />-------------------------<br /><br />Hope this was useful<br /><br />Tink

Finally my response, and here we are...

My concern with saying that those URIs describe component sets is that we will keep running into this issue as we introduce more component sets (e.g., mobile) and folks who think they know XML expect namespaces to describe what theyre about to see, not a version attribute. Having a language namespace allows us to formalize MXML to be its own thing and have the components that are used as part of Flex be abstracted. It opens things up in the future to say that MXML is about things like states and binding and object construction, regardless of whether your framework uses components in the Spark architecture, the Halo architecture, or some other engine generated via other tools. When weve asked some folks to say what is the soul of Flex the top answers are MXML and binding, its not the specific components.

Pete's response:

Well, Im not pushing hard for the idea that tag is a hack (it was merely the last of several alternatives that I presented) Im simply trying to explore all possibilities to help users avoid declaring namespaces in CSS for the 80% use case for most MXML files. I dont want our discussion to focus on one alternative, so I concede its a hack and remove that part from the discussion. For styles, the problems are type selectors. We know namespaces are one way around the problem. The question is whether there is a pay-as-you-go solution?

I am also trying to avoid formally declaring separate language namespaces as I believe that while it helps us think about things internally it really isnt buying our customers anything. I dont see MXML 2006 and MXML 2009 as language namespaces and thus I dont see them as confusing when put together. I see them as URIs that describe component sets, one of which we use today and our customers are intimately aware of, and the other is just a variation on this theme with new extensions. There may be very special tags but weve always had these and people can understand that they are not components.

Im fine with telling people that only spark components live in MXML 2009.

Ely's thoughts:<br /><br />My short two cents:<br /><br />- I agree with Matt, letting customers mix the two language namespaces in the same document feels confusing as all hell. <mx:Script> and <fx:Script> in the same document just doesnt make sense in my mind. I think we need to either <br /> 1) accept that the tool ameliorates the namespace confusion enough for new users that we should have separate language and library namespaces, <br /> 2) support a per-file import capability to merge classes into namespace, eliminating multiple namespaces in most cases, or<br /> 3) decide that we want to tell the Flex4/Halo users to suck it up, and put only Gumbo into the 2009 namespace.<br /> <br />- the idea that the prefix of the style tag bleeds into the default scope of the selectors inside the CSS feels hacky. Does it decorate any selector in the CSS, or only those that match? Can you put <Style> in any namespace, and have it imply the default resolution of the CSS? If were going to do this, we need to bite the bullet as just require namespaces in CSS.

My reply to Pete

Well, I think actually combining the language and the components when both component sets are likely to be required (I believe that in Flex 4 this is going to be very common due to the lack of solid data controls in Spark, not uncommon) is going to end up being more confusing than less. A few things that bother me:
having both 2006 and 2009 namespaces in the same document, theres nothing that helps the user understand what distinction they provide and the inconsistency in format is pretty glaring
allowing language tags to come from both namespaces and have different meanings, putting in the same document would feel absolutely wrong to me
For point iii with cut and paste, Im not especially worried because someone could make the halo namespace use the mx prefix and if there was script or style code it would either be simple for the user to fix or we could even take on work in the tool to detect the scenario and fix up the prefixes if language tags were in the example. I disagree that having components in the language namespace provides more of a benefit as to saying what components are Adobes. Everyone will figure that out pretty quick regardless of namespace.

Id like to hear other opinions on this.

In the end much of this comes down to whether we think new users can handle their first application requiring multiple namespaces. If the answer is yes, then I prefer my solution. If the answer is no, then we need to come up with a mechanism that allows for a single namespace to provide necessary components (the enhancement I had listed is one approach, but it certainly has drawbacks such as source code portability). How we go about solving that is frankly what led us to deciding it was easier to just prefix the components.

Pete's example code looks like:

<Application xmlns="http://ns.adobe.com/mxml/2009" xmlns:mx="http://www.adobe.com/2006/mxml" version="4">



  <Script>



  </Script>



  <Style>

    @namespace mx "mx.controls.*"; /* Package based? */

    @namespace mx "http://www.adobe.com/2006/mxml"; /* Namespace based? */



    Button { color:#FF0000 }

    mx|Button { color:#00FF00 }

    CustomButton { color:#0000FF }

  </Style>



  <Declarations>

    <HTTPService id="myService" />

    <mx:EmailValidator id="myValidator" />

  </Declarations>



  <states>

    <State name="foo" />

    <State name="bar" />

  </states>



  <mx:VBox width="100%" height="100%">

    <mx:Button id="haloButton" />

    <mx:DataGrid id="haloDG" />

    <d:CustomButton xmlns:d="com.mycompany.*" />

  </mx:VBox>



  <Group id="sparkGroup" layout="...">

    <Button id="sparkButton" />

    <List id="sparkList" />

    <mx:DataGrid id="haloDG2" />

  </Group>



</Application>

Alright, trying to get the threaded discussion going. Here is a message from Pete Farland.<br /><br /> <br />I understand why we proposed a formal language namespace, but I feel this is an academic distinction that doesnt improve our customers day-to-day coding experience. Id like us to modify this proposal and avoid the formal distinction between language and component namespaces. Customers will feel comfortable dealing with MXML namespaces and their own custom namespaces as they did in Flex 3. The difference in Flex 4 is that we introduce an MXML 2009 namespace and then we just need to solve the issues that introduces.<br /> <br />i) To imply which language rules apply, I want to resurrect Elys suggestion of a top-level version attribute (FXG has this concept). <br />We need to handle the situation when this attribute is not present. This is a bit of a hack, but if only the MXML 2006 namespace is present, we assume a Flex 3 file so a version=3 attribute is implied. Otherwise, we would use the current default version of the compiler - which in Flex 4 is version=4. Note our tools should always generate this attribute for new MXML files that it creates.<br /><br />&lt;Application version=4 xmlns=http://ns.adobe.com/mxml/2009 xmlns:mx=http://www.adobe.com/2006/mxml <a href=http://www.adobe.com/2006/mxml&gt;<br /><br />ii) For style disambiguation, I have several ideas:<br /><br />a. Use @namespace to allow a package to be declared, and the compiler generated code would use this to generate qualified classes in type selectors. The runtime style subsystem would be updated to handle these qualified types. If we could find a way to make this only necessary when disambiguation was needed that would be even better.<br /><br />Note: It seems we would need some runtime awareness of qualified types regardless of which solution we pick.<br /><br />b. Use @namespace to allow a URI to be declared. This is just one step removed from mapping a URI to a fully qualified class name. The compiler resolves this to a fully qualified class name as it would an MXML tag. The runtime would again have to handle type selectors that were fully qualified. This is similar to your current proposal, but Id like us to work out how to make this optional and only required for disambiguation.<br /><br />c. As a short cut, imply the qualified component from the namespace of the <mx:Style> or <Style> tag. MXML 2006 style declarations are separate from MXML 2009.<br /><br />iii) Retaining our framework components in MXML namespaces. This has a lot of benefits... It identifies which components are Adobes. It means that for MXML 2006, halo based code can easily be cutnpasted from existing examples. Its not that much of a stretch for people to think of MXML 2009 as a natural progression of MXML 2006. Im not concerned that language tags appear in two namespaces only the language tags that were valid in MXML 2006 remain valid, in 2009 we simply have a superset of language tags that is extended to include Private, Declarations, Library, Definition, DesignLayer, etc... which would not be allowed in MXML 2006.<br /><br />Since we do not expect people to mix MXML 2009 and MXML 2006 in every file, theres no reason to include halo visual components in MXML 2009. The exceptions to this rule are likely non-visual (faceless) components such as services, which your proposal mentioned too.<br /><br />Anyway, Id prefer us to hash out issues of this proposal or just two namespaces than go back to the language/spark/halo proposal.

The current solution, using prefixes.

<!--

  Single MXML namespaces that reflects the language and all

 components that are in it.  Similar to how Flex 3 and earlier work.

-->

<Application xmlns="http://ns.adobe.com/mxml/2009">

 

  <!-- tags related to the MXML language are in the language namespace -->

  <Script>



  </Script>

 

  <!--

    Styles cannot support classes with overlapping names.  Basically

 if you know two classes exist with the same name you will be forced

to use CSS class selectors and the styleName property.

  -->

  <Style>

   

    Button { color:#FF0000 }

    FxButton { color:#00FF00 }

    .myCustomButton { color:#0000FF }

 

  </Style>

 

  <Declarations>

    <HTTPService id="myService" />

    <EmailValidator id="myValidator" />

  </Declarations>

 

  <!-- states are part of MXML 2009 -->

  <states>

    <State name="foo" />

    <State name="bar" />

  </states>

 

  <!-- Halo components, supports mixing Spark but not recommended -->

  <VBox width="100%" height="100%">

    <Button id="haloButton" />

    <DataGrid id="haloDG" />

  </VBox>

 

  <!-- Spark components, can support mixing Halo -->

  <Group id="sparkGroup" layout="...">

    <FxButton id="sparkButton" />

 <FxList id="sparkList" />

 <DataGrid id="haloDG2" />

  </s:Group>

 

</Application>

The primary objection to this approach is the perceived ugliness of the "Fx" prefix on components. Confusion still potentially remains for a new user to know which component they should use, answer basically is if you see a version with an Fx prefix use that, otherwise don't. Code hinting in the tool can be updated to hint "FxBut" even if the user just types "But". ASDoc is clearly delineated just by virtue of the different class names. Docs can make reference to components by name. However, we may want searches in docs to bring up FxButton even if the search was just for Button.