incubator-flex-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Left Right <olegsivo...@gmail.com>
Subject Re: Flex and names spaces in MXML
Date Wed, 14 Mar 2012 12:11:40 GMT
It doesn't really work that way. Especially not since Flex 4.
There was an attempt at having no namespace at all and to assume mx
namespace to be the default. But since in Flex 4 there are a lot of
components in the SDK that come in two flowers, but with same names, but
not only that, the code generation has changed, you must have the namespace
specified on the top-level component tag.

Now, what is the use of the namespace in MXML: you should probably first
find all the *-manifest.xml files in the framework folder of the SDK to see
where it comes from. So, namespace maps arbitrary components under the same
"package". I can imagine this was a more of an forced move, because,
originally, MXML would understand namespaces to be the package names. For
example:

<flash:Sprite xmlns:flash="flash.display.*"/>

Now imagine an average MXML template - it may use components from tens of
different packages, so your top-level tag would looks something like:

<flex:Application
  xmlns:flex="mx.core.*"
  xmlns:bindings="mx.bindings.*"
  xmlns:utils="mx.utils.*"
  . . .
  >
  . . .
</flex:Application>

That's another... doubtingly useful feature of MXML design... while in AS3
you only need to import into scope once, and you don't need to mention the
source, unless there is ambiguity, XML format doesn't allow this kind of
approach (why use XML for programming language templates is another tough
question, I'm not trying to ask at the moment...)
So, ultimately, that would be a step backwards to the situation, where you
have to write the package and the imported class all the time.
The compiler attribute `-namespace` came to rescue: so you can group
classes into the same namespace regardless of their actual
namespace/package. This is still not as good as normal AS3 way to deal with
the problem, but it reduces the verbosity, so that's the reason to use it.

So, if this problem was to be addressed, maybe it would be possible to add
a compiler argument `-default-namespace` that would have to match a
namespace from those available to the project and would be implied when
resolving components. So you would only need to specify a namespace for the
foreign code.
This has it's downside as it might be too complex for an average user to
configure and is prone to subtle errors - results of naming collisions.

Best.

Oleg

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message