Fx prefix revisited

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.

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.