我是Flex的新手，我不喜欢你编写命名空间mx的方式：为你编写的每个控件声明。它使代码变得杂乱无章。我想写一下：
<Panel ...
而不是
<mx:Panel ...
我试着写
xmlns="http://www.adobe.com/2006/mxml"
表示顶级元素而不是
xmlns:mx="http://www.adobe.com/2006/mxml"
在顶级声明中。这项工作在一定程度上，但打破了一些现有的代码。例如，文档中定义的XML数据都附加了aaa：作为运行时的命名空间。我还在我的小样本程序中注意到了其他问题。
有没有办法做到这一点，或者这是一个失败的原因？以及一些关于为什么会受到赞赏的背景信息。
更新：感谢大家的回复，但我希望听到一些人真正尝试过这一点，并认为这很重要。虽然你们大多数人告诉我这是一个坏主意，但我并没有气馁。我现在顺利地以这种方式工作了几个程序。并计划在我的所有flex应用程序中执行此操作。一个技巧似乎对我有用，虽然我不能说它会普遍起作用。如果您需要在doc中使用单独的命名空间，例如，使用HTTPService参数，您可以在该元素中创建一个命名空间，如下所示：
<HTTPService id="service" url="http://blah.com"
method="POST" result="gotResult(event)">
<request xmlns:p="*">
<p:param1>p1</p:param1>
<p:param2>p2</p:param2>
</request>
</HTTPService>
希望这有助于某人。我对我的代码现在的干净程度非常满意，几乎和普通的html文件一样干净。至于那些认为写mx的人：在整个代码中更清楚，什么不是，我完全不同意。我认为要求你在代码中过度重复相同字符序列的语言 - 你应该考虑一个文档 - 有设计缺陷。这里有一个类比：如果你正在读一篇关于巴拉克奥巴马的文章，你会喜欢它吗？每一句话都包含“巴拉克奥巴马”的字样，那会不会很烦人？
答案 0 :(得分：7)
我认为删除mx命名空间几乎肯定会在项目变大时导致名称冲突问题。
我个人认为mx命名空间使代码更清晰而不是更混乱，特别是如果你有基于组件的flex开发或许多你自己的控件。在过去的两年里，我拥有一个大型的灵活代码库，我发现mx名称空间不引人注目，特别是当你有内嵌的自定义对象时，例如项目渲染器。
我的建议（非科学断言）是忍受它，特别是如果你在删除它时发现问题。我打赌你会在一段时间后停止注意它。
答案 1 :(得分：2)
您需要mx或某些xmls：[SOMETHING HERE]因为这是引用控件定义的XML命名空间。这就像在普通代码中使用命名空间一样。
只是编写Panel是模棱两可的，可能与另一个人的Panel实现冲突。所以我们向Flex声明了什么名称空间面板属于（http://www.adobe.com/2006/mxml），我们用mx将其别名。
微软的WPF XAML也需要这个。
答案 2 :(得分：2)
只是成为分歧的声音......
在挖掘Ely Greenfields代码时，他做了很多 - 我不确定Flex SDK团队中的其他开发人员是否这样做但是它确实为这样做提供了一些信任...... ？
答案 3 :(得分：1)
我同意这里的大多数其他答案，最好留下它。最终，您将希望将其他命名空间用于自定义组件等事物，然后您需要一个命名空间来进行区分。然后你会有一些带有命名空间而有些没有。
我想说，如果没有其他原因，你应该离开它，因为有一天其他人可能不得不查看你的代码，他们可能会发现它比mx更可读。
答案 4 :(得分：0)
mx：只是告诉Flex Panel（以及任何其他组件）是Flex框架的一部分的一种方式，它内置于Flex中。这有助于Flex知道在哪里查找Panel，并使您的编译过程更快。
您还可以使用local：来访问您创建的组件。示例：如果我想向Panel添加一些功能，我会输入一些代码，并将其另存为自定义面板，称为MyPanel。他们，我可以用来告诉Flex MyPanel是我的组件，它可以找到我的项目中的某个地方。当然，你可以任意命名： - ）
我同意你的观点，mx：起初看起来很不雅观，特别是当你已经拥有HTML或XML的强大背景时，你会习惯它。
答案 5 :(得分：0)
请记住，如果您正在开发应在包括移动设备在内的各种平台上运行的应用程序，最好尽可能坚持纯粹的火花，因为现在大多数移动设备都支持它。例如，有些人被迫使用像手风琴这样的mx控件。在这种情况下，如果你有时间实现它，最好使用工具或spark中的基本控件来创建这些更高级或更复杂的控件来代替使用。