Flex--Use Flex的命名空间 ：mx_internal

      有时候你想改变一个Flex组件的行为, 但是它藏在私有方法或者私有变量后面， 所以你不能取得它 ，许多Flex framework里的组件有些方法和属性被标记为mx_internal命名空间，这样你就可以访问藏在私有方法或者私有变量后面的东东了。这东东官方说是会随时变动的，请注意使用！

What is mx_internal ?

    Traditionally in OOO languages access specifiers are used to control visibility of declarations (public, private, protected). Now with XML based languages like MXML making debut, a new mechanism for controlling visibility of declarations has evolved… using namespaces. Namespaces are essentially custom access specifiers, which can have names of your choosing. Namespaces are outfitted with a Universal Resource Identifier (URI) to avoid collisions, and are also used to represent XML namespaces when working with E4X. 

以下是来自http://codeofdoom.com/wordpress/2009/03/12/when-and-how-to-use-mx_internal-in-flex/外国朋友的博客中讲解的,讲的不错,就直接引用了：

How many times have you hopped into Flex’s source code only to see the modifier “mx_internal”? No public, private or protected, just mx_internal. It is everywhere in there. But what is it? Turns out, according to Adobe, it is a namespace used to flag functions and properties within the framework that may change in future releases. Obviously, since they might change, Adobe, with all its motherly goodness, hides these properties and functions from us behind this namespace. This does not mean we cannot access them though. We just have to jump through a few small loops. This article will go over how and when to use mx_internal, but also what to be careful about when using them. 

How to use mx_internal 

Using it is pretty straight forward and simple. All you have to do is include these lines :

 Note that this needs to be done after all other imports，必须所有的引入完之后再引入。

 import mx.core.mx_internal; use namespace mx_internal;  

 

 and BAM! You now have access to mx_internal. Another way you can access it is like this:

 object.mx_internal::inputField.restrict; 

I prefer this method myself*. It allows whomever is looking at the code that you are accessing something marked mx_internal vs doing a blanket import. This is a pain whenever you come back to your code and you dont realize what is using mx_internal and what is not. It will make the code a little more cumbersome, but it does help for clarification purposes. I suppose you could always put comments next to your code that uses it, but its my experience that no one really comments properly (including myself).

What do you get when you use mx_internal 

It is kind of nice when you use mx_internal for the first time, because you are given access to all sorts of new things within a component that you did not have access to before. Here is a easy way of showing you. These are some properties within a panel that you have access to normally:

 

 and with mx_internal turned on, you now have these:

 the variables are color coded as below
o Red Rectangle – private
o Green Circle – public
o Yellow Rhombus – mx_internal
o Char codes “C” & “S” – constants and static vars

 

 

 

 

As you can see, there are all these new fields you have access to, which are marked with the yellow rhombus.Isn’t that great? All these new properties waiting to be explored. Lets take a look at what we can do with some of these. 

Examples with mx_internal 

I saw this example somewhere else, but it is a nice easy example that involves the NumberStepper component, which consists of a TextInput and two Buttons (for stepping up and down). What is annoying is that you can type whatever numbers you want in that inputBox. What if I want to make it so you cant edit it? I could try that enabled property on there, but that disables the whole thing. I dont want it disabled. Unfortunately, we are not given direct access to this component. Luckily we can still get to it via mx_internal.<mx:Application xmlns:mx="http://www.adobe.com/2006/mxml" layout="absolute" creationComplete="complete()" > <mx:Script> <!--[CDATA[ public function complete():void{ stepper.mx_internal::inputField.editable = false; } ]]--> </mx:Script> <mx:HBox id="hbox"> <mx:NumericStepper id="stepper" /> </mx:HBox> </mx:Application>  

 

If we do this, we will still be able to change the values via the buttons, but you will not be able to physically edit the values inside of the TextInput. Speaking of buttons, are you bored with those up and down arrows? Well with access to the mx_internal, we can change those icons.

[Bindable] [Embed(source='../red.png')] private var redIcon:Class; public function complete():void{ stepper.mx_internal::inputField.editable = false; stepper.mx_internal::nextButton.setStyle("icon",redIcon); stepper.mx_internal::prevButton.setStyle("icon",redIcon); }  

 

giving us this: 

 

I added a red.png (a small red square) to our project. After that, I added the following lines to our program and complete() function, giving us a fashionable look to our new buttons.

Of course, this is for the sake of example. Your buttons in real life would much better. Here is another example I dug up. Creating Alert boxes with non-selectable text.
public function complete():void{ var a:Alert; a = Alert.show("Hey Look text!!", "i cant select it!", Alert.OK | Alert.CANCEL); a.mx_internal::alertForm.mx_internal::textField.selectable = false; }  

 

Once again, the alertForm within the Alert object has a textField on it. We are simply using mx_internal to each it.

 

The pain of mx_internal 

Before I mention the obvious problem, here is what is kind of a pain. These are things that Adobe does not officially support. It is not like these are properties they let you know about in advance. Most of the time, you will have to dig down into the source of Flex to see what is available to you. Alternatively, you could just use mx_internal and scroll through your new properties as well, but I prefer looking at the source.

One way to help you find things you have access to is to remember that most of the build in components are Composite Components, which are components built from one or more components. The NumericStepper is a perfect example. Just by looking at it, you know you have a TextInput and two Buttons.

Of course, a quick hop into the source, you can see within the createChildren() method what components are being added to it (you might remember from this post what createChildren() is and how it is used) . Once you reference them via mx_internal, you can just treat them as if they were normal components.

The obvious pain is directly from what Adobe tells us in the Flex docs.
mx_internal is a namespace used by the Flex framework to partition out functions and properties that may change in future releases of the Flex SDK. 

 

Yep. Whatever you use with mx_internal IS SUBJECT TO CHANGE. This is why it is hidden away from us. However, I do have a hard time believing they are going to replace a TextField within the NumericStepper. I suppose in Gumbo or a future release of Flex, they might have an AdvancedTextField and use that instead? I am just thinking out loud.

Personally, if I can avoid it, I try to keep mx_internal out of a framework. If it is a framework that is going to be continued internally, that is fine. You could always fix it. If you develop a framework that is shipped off to the client for their use and that mx_internal DOES in fact change, be prepared to have an angry client.

Whenever I get a chance to mess with mx_internal(which is not often), I feel like I am exploring a dangerous uncharted land. I am fairly unfamiliar with those parts. You have to be careful with it. However, you do get to do some pretty cool stuff! While it may be a mystery right off the bat, it is incredibly easy to dive into to play around with.

*There is another reason why this is the preferred method to use. If you look at the example I gave with showing the new methods in the intellisense, I used an Panel. If you try to do the same thing with the NumericStepper, you will notice they do not show up there. The only reason I can come up with is because the components that DO NOT show the mx_internal fields are already using the mx_internal namespace. If this is incorrect, by all means, please correct me!