1 2 Previous Next 72 Replies Latest reply: Feb 19, 2009 1:42 AM by (Joseph_Balderson) RSS

    Fx prefix revisited

    matt_chotin Community Member
      Alrighty, we promised we'd have further discussion about this on the forums, so here we go. Since I think the email system can't handle really long posts, I'm going to post a series of things that I've written up, along with some responses that started among the team. We'll take things from there.

      Solving the naming convention with regard to overlapping classnames is especially difficult when you take a number of factors into account. Here are some of the things to consider as we look to address the issue (not prioritized and not exhaustive):

      These issues can be attributed to general use and the SDK:
      - Flex 4 aims to be compile-time compatible with Flex 3. This means that we cannot rename existing classes nor break major interface contracts.
      - Given we can't rename existing classes, what package naming structure makes sense if new classes will overlap with existing.
      - How does CSS differentiate between classes with the same local name (class name)
      - How will new users understand the differences between Spark and Halo classes, and especially understand when there is overlap
      - What should documentation do to differentiate between Spark and Halo controls, and how do we control which page a user arrives at when searching
      - How will someone reading code easily understand which control the code is using
      - Given the change in architectures, how does someone easily know which architecture a component belongs to
      - The number of overlapping controls between Spark and Halo will increase after Flex 4, Spark will receive new controls over time

      These issues can be attributed to an IDE (any of 'em):
      - How does code hinting work when you have overlapping classes (what can it do to help differentiate)
      - If a list of components is in a panel, how do those components get differentiated
      - 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
      - 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

      Next up: the current situation.
        • 1. Re: Fx prefix revisited
          matt_chotin Community Member
          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.
          • 2. Re: Fx prefix revisited
            matt_chotin Community Member
            A proposal that does not use class name prefixes:

            NOTE: I have chosen the specific namespace prefixes for the sake of discussion and recommend not spending
            too much time on what prefix goes with what namespace. Also note that this does not include a recommendation
            for the AS packages to use.


            <!--
              There are 3 primary namespaces in a mixed Spark/Halo document:
              1) http://ns.adobe.com/mxml/2009 is the language namespace for MXML.  All language tags need to be in this
            namespace.
              2) library://ns.adobe.com/flex/spark is the namespace for the Spark manifest.  All components that are
            part of the Spark architecture are found here.
              3) library://ns.adobe.com/flex/halo is the namespace for the Halo manifest.  All components that come from
            the Halo architecture are found here.
              Any faceless component that was not part of the Halo or Spark architecture specifically (e.g., Validators,
            Formatters, Services) are available in both the Spark or the Halo namespace for convenience.
            -->
            <s:Application xmlns="http://ns.adobe.com/mxml/2009"
              xmlns:s="library://ns.adobe.com/flex/spark"
              xmlns:h="library://ns.aodbe.com/flex/halo">

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

              </Script>

              <!--
                Styles will need to be in namespaces.  You refer to types via the manifests and if a manifest doesn't
            exist you can use packages. Everything must be in a namespace, in this example we do not provide the default
            namespace; we could provide a compiler option that specifies the default namespace if otherwise unspecified
            (and we'd need to decide if that was Spark or Halo).  Namespaces translate into full qualfied classnames for
            lookup purposes.
              
                We could also decide that a namespace of * would just match up with anything, developer-beware.  That
            way you could avoid having to set up namespaces for components where you're confident there won't be a
            naming overlap.  And we could make the default namespace be that if we wanted too... Note that * is matched
            at runtime and cannot be verified at compile-time.  The CSS spec does define * and we could choose to more
            closely match its suggestions. Note that having support for unqualified namespaces means a runtime cost for
            two lookups, one looking for the fully qualified and one looking for unqualified, though this is likely done
            once when building the style chain per component instance.
              -->
              <Style>
              
                @namespace h "library://ns.adobe.com/flex/halo";
                @namespace s "library://ns.adobe.com/flex/spark";
                @namespace my "com.mycompany.flexproj.*";
              
                s|Button { color:#FF0000 }
                h|Button { color:#00FF00 }
                my|CustomButton { color:#0000FF }

              </Style>

              <Declarations>
               <!-- Can be confusing and use both namespaces for the faceless components, though we can recommend
            using Spark -->
                <s:HTTPService id="myService" />
                <h: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 -->
              <h:VBox width="100%" height="100%">
                <h:Button id="haloButton" />
                <h:DataGrid id="haloDG" />
              </h:VBox>

              <!-- Spark components, can support mixing Halo -->
              <s:Group id="sparkGroup" layout="...">
                <s:Button id="sparkButton" />
            <s:List id="sparkList" />
            <h:DataGrid id="haloDG2" />
              </s:Group>

            </s:Application>


            The biggest issue with this approach is the distinction created between language tags and component
            libraries. You have to immediately become aware of namespaces when using MXML, not just when using your own
            components. Is that really a problem for new users? Is this something that tooling can help with in a way
            that is acceptable for the SDK to not deal with on its own? Flex Builder as an example already will insert
            namespaces for you and doesn't require the namespace prefix when doing code hinting. And generated code
            based on dragging things out from a panel would obviously be correct. Which namespace do they use for a
            given component? A reasonable answer is: try Spark, failing that try Halo. And the tool can basically do
            that for you since you just start typing the component name. See further down for a potential enhancement
            when using MXML.

            ASDoc will now introduce more confusion as similar components will be right next to each other. We'd need
            to do something like put icons next to each entry indicating which architecture it's a member of. The
            documentation books will also need to refer to components by architecture, delineation by class name will
            not be enough unless fully qualified. Searching via a search engine will also bring up results from both
            architectures, much cross-linking will be needed.

            The tool will need to hint not just by class name but by package name, it may also benefit from showing an
            icon related to the architecture.

            An enhancement that can help address the MXML namespace issue for many users is to allow the consolidation
            of namespaces. We already have support in flex-config to allow one namespace to "import" another. We could
            therefore have flex-config import the Spark namespace into the MXML 2009 language namespace. That way only
            Halo would be in a separate namespace from the main namespace. This is forwards-compatible.

            Additionally we could take the non-overlapping Halo components and put them in the main namespace. Most
            users would then just use the single namespace and only if you knew you wanted an overlapping Halo would you
            need to use the Halo namespace. This is NOT forwards-compatible as the number of overlapping components
            will grow in future versions of Flex.

            If we were to use this enhancement I think it might be acceptable to do the merging of Spark and the
            language namespace in the default version of flex-config.xml and allow documentation to take advantage. I
            would not recommend adding Halo into the namespace by default. We would not however remove the separate
            Spark namespace, as those who wanted to remain especially formal could change the flex-config to require
            explicit namespace usage for each architecture. It should be noted that using the import capabilities that
            are set in a config file as opposed to on a per-MXML file basis could lead to problems with source code
            portability, as different environments may have different imports set up.
            • 3. Re: Fx prefix revisited
              matt_chotin Community Member
              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.
              • 4. Re: Fx prefix revisited
                matt_chotin Community Member
                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.
                • 5. Re: Fx prefix revisited
                  matt_chotin Community Member
                  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>
                  • 6. Re: Fx prefix revisited
                    matt_chotin Community Member
                    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.
                    • 7. Re: Fx prefix revisited
                      matt_chotin Community Member
                      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.
                      • 8. Re: Fx prefix revisited
                        matt_chotin Community Member
                        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.
                        • 9. Re: Fx prefix revisited
                          matt_chotin Community Member
                          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.
                          • 10. Re: Fx prefix revisited
                            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
                            • 11. Re: Fx prefix revisited
                              Constantin Ehrenstein MeganK
                              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.
                              • 12. Re: Fx prefix revisited
                                Constantin Ehrenstein MeganK
                                sorry: double post.
                                • 13. Re: Fx prefix revisited
                                  Simeon Bateman Community Member
                                  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.
                                  • 14. Re: Fx prefix revisited
                                    Community Member
                                    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.
                                    • 15. Re: Fx prefix revisited
                                      bclinkinbeard Community Member
                                      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.
                                      • 16. Re: Fx prefix revisited
                                        ChivertonT CommunityMVP
                                        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).
                                        • 17. Re: Fx prefix revisited
                                          matt_chotin Community Member
                                          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.





                                          • 18. Re: Fx prefix revisited
                                            bclinkinbeard Community Member
                                            > 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.
                                            • 19. Re: Fx prefix revisited
                                              mjethani
                                              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!
                                              • 20. Re: Fx prefix revisited
                                                matt_chotin Community Member
                                                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.





                                                • 21. Re: Fx prefix revisited
                                                  bclinkinbeard Community Member
                                                  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.
                                                  • 22. Re: Fx prefix revisited
                                                    Alan Klement
                                                    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).
                                                    • 23. Re: Fx prefix revisited
                                                      Community Member
                                                      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).
                                                      • 24. Re: Fx prefix revisited
                                                        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.
                                                        • 25. Re: Fx prefix revisited
                                                          mjethani Community Member
                                                          @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
                                                          • 26. Re: Fx prefix revisited
                                                            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
                                                            • 27. Re: Fx prefix revisited
                                                              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
                                                              • 28. Re: Fx prefix revisited
                                                                renaun Community Member
                                                                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.
                                                                • 29. Re: Fx prefix revisited
                                                                  Peter Farland Adobe Employee
                                                                  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?
                                                                  • 30. Re: Fx prefix revisited
                                                                    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.
                                                                    • 31. Re: Fx prefix revisited
                                                                      (Josh_McDonald) Community Member
                                                                      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>
                                                                      • 32. Re: Fx prefix revisited
                                                                        Constantin Ehrenstein MeganK
                                                                        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.
                                                                        • 33. Re: Fx prefix revisited
                                                                          Community Member
                                                                          Quote:
                                                                          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?

                                                                          - If I have never seen Flex MXML and I was just getting into it I would be confused if I was able to choose Button, FxButton, fx:Button or mx:Button. If I saw, "FxButton" and "Button" I would think that, "FxButton" was an alternative choice. I think if you type "Button" that would be the recommended option to choose. If Spark is the future than "Button" or "fx:Button" should be the default. I might be confused on what we've established so far in this discussion but I can't see a new user understanding the distinction the "Fx" prefix is making any better than using a namespace to establish it.

                                                                          I think trying to remove the namespaces altogether is causing a lot of these issues. I like them and think it makes MXML stand out but I can see that others would want that. I think if you get a new developer and show them a mxml file without any namespaces they may understand it quicker but they are going to see namespaces sooner or later. Either in the documentation or in the multitude of examples online. It's a temporary tradeoff that seems to be causing a lot of problems. It's when you show them what Flex can do that you sell them.

                                                                          Judah
                                                                          • 34. Re: Fx prefix revisited
                                                                            DustyJ Community Member
                                                                            Maybe it's just that the opposition to the Fx is so vocal, and those in support of it think that Adobe won't change it, but I feel odd for voicing my support for Prefixing the new components. I'd actually go further and suggest using SparkButton over FxButton, putting the absurd "GxButton" argument to rest.

                                                                            I don't care about mxml, even though I know that beginner users will find the difference between Button and SparkButton much easier to understand that Button and fx:Button are the same thing, but mx:Button is different, unless the person that wrote the file made mx the * namespace, which means that Button and mx:Button are the same thing, and fx:Button is different.

                                                                            I'm kinda pissed that if prefixing goes through, I might have to start declaring all of the crossover components as:
                                                                            var fxb:fx.controls.Button = new fx.controls.Button
                                                                            var mxb:mx.controls.Button = new mx.controls.Button

                                                                            Seriously? How easy is that to scan through? Why have import statements at all?

                                                                            Now imagine casting your event objects:
                                                                            var b:mx.controls.Button = event.currentTarget as mx.controls.Button;
                                                                            var c:fx.controls.Button = fx.controls.Button(event.currentTarget);

                                                                            And yes, we will be supporting both mx and fx buttons in the same code for some time, as we'll be up to about 100 modules + 5 libraries by the time Flex 4 is released, and convincing management that we have to have a month or two to convert everything over will be impossible.

                                                                            (and my head starts to hurt just thinking about the mess that our css files will turn into... our designers heads might explode)
                                                                            • 35. Re: Fx prefix revisited
                                                                              (Josh_McDonald) Community Member
                                                                              I think if you're building one component with both mx.core.Button *and* mx.gumbo.Button (or whatever it is) from ActionScript, you're definitely doing something that's going to make your code ugly either way. And if you're only importing one "Button" and one "Container", your code won't be any harder to read for one being in Halo and one being Spark.


                                                                              -Josh

                                                                              On Wed, Feb 11, 2009 at 1:13 PM, Dusty Jewett < member@adobeforums.com> wrote:

                                                                              A new message was posted by Dusty Jewett in



                                                                              Developers --

                                                                                Fx prefix revisited



                                                                              Maybe it's just that the opposition to the Fx is so vocal, and those in support of it think that Adobe won't change it, but I feel odd for voicing my support for Prefixing the new components. I'd actually go further and suggest using SparkButton over FxButton, putting the absurd "GxButton" argument to rest.


                                                                              I don't care about mxml, even though I know that beginner users will find the difference between Button and SparkButton much easier to understand that Button and fx:Button are the same thing, but mx:Button is different, unless the person that wrote the file made mx the * namespace, which means that Button and mx:Button are the same thing, and fx:Button is different.


                                                                              I'm kinda pissed that if prefixing goes through, I might have to start declaring all of the crossover components as:

                                                                              var fxb:fx.controls.Button = new fx.controls.Button

                                                                              var mxb:mx.controls.Button = new mx.controls.Button

                                                                              Seriously? How easy is that to scan through? Why have import statements at all?

                                                                              Now imagine casting your event objects:

                                                                              var b:mx.controls.Button = event.currentTarget as mx.controls.Button;

                                                                              var c:fx.controls.Button = fx.controls.Button(event.currentTarget);

                                                                              And yes, we will be supporting both mx and fx buttons in the same code for some time, as we'll be up to about 100 modules + 5 libraries by the time Flex 4 is released, and convincing management that we have to have a month or two to convert everything over will be impossible.


                                                                              (and my head starts to hurt just thinking about the mess that our css files will turn into... our designers heads might explode)





                                                                              View/reply at Fx prefix revisited

                                                                              Replies by email are OK.

                                                                              Use the unsubscribe form to cancel your email subscription.





                                                                              --
                                                                              "Therefore, send not to know For whom the bell tolls. It tolls for thee."

                                                                              Josh 'G-Funk' McDonald
                                                                                -   josh@joshmcdonald.info

                                                                                -   http://twitter.com/sophistifunk
                                                                                -   http://flex.joshmcdonald.info/

                                                                              • 36. Re: Fx prefix revisited
                                                                                bclinkinbeard Community Member
                                                                                Why would you ever need to instantiate fx.controls.Button and mx.controls.Button? There is simply no reason to ever do that.



                                                                                On Tue, Feb 10, 2009 at 10:13 PM, Dusty Jewett < member@adobeforums.com> wrote:

                                                                                A new message was posted by Dusty Jewett in



                                                                                Developers --

                                                                                  Fx prefix revisited



                                                                                Maybe it's just that the opposition to the Fx is so vocal, and those in support of it think that Adobe won't change it, but I feel odd for voicing my support for Prefixing the new components. I'd actually go further and suggest using SparkButton over FxButton, putting the absurd "GxButton" argument to rest.


                                                                                I don't care about mxml, even though I know that beginner users will find the difference between Button and SparkButton much easier to understand that Button and fx:Button are the same thing, but mx:Button is different, unless the person that wrote the file made mx the * namespace, which means that Button and mx:Button are the same thing, and fx:Button is different.


                                                                                I'm kinda pissed that if prefixing goes through, I might have to start declaring all of the crossover components as:

                                                                                var fxb:fx.controls.Button = new fx.controls.Button

                                                                                var mxb:mx.controls.Button = new mx.controls.Button

                                                                                Seriously? How easy is that to scan through? Why have import statements at all?

                                                                                Now imagine casting your event objects:

                                                                                var b:mx.controls.Button = event.currentTarget as mx.controls.Button;

                                                                                var c:fx.controls.Button = fx.controls.Button(event.currentTarget);

                                                                                And yes, we will be supporting both mx and fx buttons in the same code for some time, as we'll be up to about 100 modules + 5 libraries by the time Flex 4 is released, and convincing management that we have to have a month or two to convert everything over will be impossible.


                                                                                (and my head starts to hurt just thinking about the mess that our css files will turn into... our designers heads might explode)





                                                                                View/reply at Fx prefix revisited

                                                                                Replies by email are OK.

                                                                                Use the unsubscribe form to cancel your email subscription.



                                                                                • 37. Re: Fx prefix revisited
                                                                                  Hi,

                                                                                  my suggestion for the default set of namespaces:
                                                                                  • MXML 2006 language namespace as we know it
                                                                                  • MXML 2009 language namespace that will contain the spark components, halo components that are not yet (or will not be) ported to spark and the remaining language constructs

                                                                                  • Halo component namespace that contains only halo components that are not in the MXML 2009 namespace
                                                                                  • Spark component namespace that contains only spark components (that are not in the MXML 2006 namespace anyway)

                                                                                  MXML 2006 and MXML 2009 namespaces can not be mixed.

                                                                                  Old Flex 3 code will still compile as it uses the MXML 2006 namespace. If a Flex application should be ported to spark, then the language namespace should be changed to MXML 2009 and compile errors (if there are any) corrected. If spark components should be added to a Flex 3 application, then it can be done through the spak component namespace. A pure Gumbo application will only need the MXML 2009 namespace.


                                                                                  As development on Gumbo goes on, everytime a Halo component is replaced with a new Spark component, it takes its place in the MXML 2009 namespace and the halo component goes to the halo component namespace.



                                                                                  Haykel Ben Jemia

                                                                                  Allmas
                                                                                  Web & RIA Development
                                                                                  http://www.allmas-tn.com





                                                                                  On Tue, Feb 10, 2009 at 10:37 PM, Peter Farland < member@adobeforums.com> wrote:

                                                                                  A new message was posted by Peter Farland in



                                                                                  Developers --

                                                                                    Fx prefix revisited



                                                                                  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?





                                                                                  View/reply at Fx prefix revisited

                                                                                  Replies by email are OK.

                                                                                  Use the unsubscribe form to cancel your email subscription.



                                                                                  • 38. Re: Fx prefix revisited
                                                                                    Constantin Ehrenstein MeganK
                                                                                    In addition to my recent post, I'd like to express my hope that the Flex SDK team will have the balls (figure of speech, no offense to the female coders) to confront Adobe's suits with the fact that the migration to the next generation of Flex won't be complete by the time Flex 4 rolls out.

                                                                                    Why not admit that we're in a substantial transition of the Flex framework which is almost impossible to complete within one product cycle?

                                                                                    Sure, code-freezing a half-baked Flex SDK for Flex 4 imposes hardships on developers of all experience levels (presumably especially the novice developers) and will definitely look kind of messy. But what are the choices?

                                                                                    1. Prettifying the half-baked mess (as developers out there might see it) with something that looks as if it was all intentional (i.e. introduce Fx prefixes)

                                                                                    2. Shrugging your shoulders, telling the Adobe suits "if you'll have to roll out Flex 4 by fall '09, there will be a half-baked framework" (i.e. mix mx: with fx: namespace)

                                                                                    3. Postponing the release of Flex 4 until the next generation of the framework is sufficiently complete and stable (i.e. provide a default namespace for the new language/components bundle, along with the opportunity to tie in legacy code via namespaces)

                                                                                    4. Opening up to the community and accepting help from veteran community developers to outsource component development so that the Gumbo language/Spark components will be ready by the time Flex 4 is supposed to ship

                                                                                    I can't help but favoring #4, followed by #3, #2, #1.

                                                                                    To me, the top priority always is the most sophisticated, consistent language. Don't forget that the migration frenzy will be over sooner or later, and I shudder with disgust when I think of some awkward glossed-over workarounds for temporary problems remaining in the MXML language.

                                                                                    Adobe made the right decision to open the Flex SDK up to the community, but now the quality of the language should not be messed with because of some Adobe specific business decision (i.e. the release time frame of Flex 4).

                                                                                    @Dusty:
                                                                                    If we stay true to the principle that the most recent fully functional language/components bundle will occupy the default language, there is no need to abolish import statements.

                                                                                    So by the time the Gumbo/Spark package isn't complete yet, we're supposed to use

                                                                                    import mx.some.Componentname;

                                                                                    myHaloComp:Componentname = new Componentname();
                                                                                    mySparkComp:fx.some.spark.Componentname = new fx.some.spark.Componentname();


                                                                                    --simply because the Halo bundle represents the last fully functional set.

                                                                                    As soon as the Gumbo/Spark bundle is ready, we use

                                                                                    import fx.some.spark.Componentname;

                                                                                    myHaloComp:mx.some.Componentname = new mx.some.Componentname();
                                                                                    mySparkComp:Componentname = new Componentname();


                                                                                    This will hold in future migration phases, too: we will always have the most recent fully functional set occupy the default namespace, with legacy or not-yet-ready additions tied in via namespaces.

                                                                                    This is a very straightforward and consistent principle which is easy to grasp, even for novice developers.

                                                                                    C.
                                                                                    • 39. Re: Fx prefix revisited
                                                                                      Namespaces is wayyyy better than FX<ComponentName>. Please dont go that way. The needed transition/mix of components is bad enough but at least do it withouth polluting component names. A Button is a Button. What is FxButton? some kind off buton with effects? Just doesn't feel right.<br /><br />What bothers me is that you are releasing a version 4(!) of a technology and that it wont be finished. I love flex but this is lame imho. Flex 3 is ok, so why not wait until all the components are ready before releasing version 4? Novice users then wont even have all the problems with mixing components, they can just use version 4 all the way. If you want to attract new users and propose flex is rather easy to learn this is the way to go.<br /><br />Experienced users wont have a problem migrating old software using extra namespaces as they are used to them anyway.<br /><br />Anyway i'll probably stick to flex 3 until 4 is really finished including all currently available components in flex 3. As it's again a complete rewrite of the components the first version probably has some bugs anyway. In the meantime libraries as degrafa will fill the gap for more primitive drawing for me.<br /><br />Sorry that i sound so negative, but im really dissaponted that flex4 won't be finished (or has a smaller component-set) at the time it will be released. But still flex is nr1 in ria..... so keep up the good work!<br /><br />Arnoud
                                                                                      1 2 Previous Next