“could not resolve <mx:…> to a component implementation”

If you have ever tried to add mx.core.ToolTip (or certain other classes) as a mxml-tag to your Flex project then you might’ve run into the following compiler-error:

“Could not resolve <mx:ToolTip> to a component implementation.”

So why does Flex (or rather MXMLC, the compiler) let you write <mx:Button> and <mx:Canvas> and all those other Flex components, but not <mx:ToolTip> — it’s a native Flex class and it’s in the mx package just like all of the others, right?

Fact is, it’s not the mx class-package that defines whether or not you can add a component by saying <mx:...>, but rather the Flex component manifest file — it describes which of the native Flex classes fall under the mx xml-namespace (or actually any namespace you want to use). I might write a post about manifest-files in Flex somewhere in the near future, but for now you’ll have to read up in the docs if you want to know more.

It so happens that the ToolTip class isn’t included in the native Flex component manifest, and consequently the compiler won’t be able to find it if you just write “<mx:ToolTip />”. You can work around this by specifying a seperate xml-namespace for the mx.controls package:



    

Note that in the above example we can’t change the value of the xmlns:mx attribute so that it would point to the mx.controls class-package, because if we would then the compiler wouldn’t recognize the <mx:Application> tag anymore (since the Application class isn’t in the mx.controls package).

Also, for the naysayers who completely miss the point and start talking about why on earth you would want to instantiate a ToolTip through mxml: To tell the truth I was wondering about this myself, but if you think about it, tooltips in Flex aren’t restricted to just having whatever you put into UIComponent.toolTip automatically pop up when you mouse-over. In fact you may want to create a custom mxml-component subclass of ToolTip and manually add it to your application using the ToolTipManager class during runtime.

That having been said, ToolTip isn’t the only Flex-class not included in the Flex component manifest, naturally what I wrote in this post also applies to any other class in the Flex framework that extends UIComponent but isn’t included in the manifest.

A different use for custom namespaces (1/2)

When namespaces were first introduced in Actionscript 3 I thought it was all pretty cool, but still I sort of had a difficult time thinking of actual use-cases.

What I initially would have liked to use custom namespaces for was to restrict access to certain properties/methods, to only be accessible for certain classes, in the way that private and protected enable you to — unfortunately there is no simple way of defining who can import your namespace, consequently rendering namespaces somewhat useless for this particular use-case.

Then some time ago it struck me that rather than defining new members with a custom namespace, that you could of course also enhance an existing method instead (I admit this might seem like a no-brainer, but it took me a while to bump into).

Let’s say you have a subclass that for regular (outside) usage needs to override a method in the superclass, but itself still needs to use the original (super-) method. You would probably just override the method in the subclass and use super.method() wherever you needed to use the original functionality.
Now let’s say that you need to make a subclass of your subclass, which would also require access to the original functionality in said method. All of a sudden super.method() will not work for you anymore.

Here’s where namespaces start coming in handy, while still simply overriding the method in the first subclass, you also implement a function with the same name but with your own namespace (for example “original”). Then whenever you need to call the original implementation you can call original::method(), regardless of how deep down in the inheritance-chain you are.

This is only one use-case, you could for instance also use this concept to work around the nasty ambiguous-reference bug you get (or used to get) when declaring a getter and a setter with different (native) namespaces.

To keep the focus on the above described concept I put the example-code in a seperate post, feel free to read on though.