Flex+MXML id 属性命名约定/最佳实践

Question

由于命名空间内存在太多潜在的污染，特别是解析器自动声明具有 id 的任何 MXML 组件可以使用该 ID 公开访问，因此我发现仅使用驼峰命名法作为 MXML 元素 id 是很危险的。

例如：

<mx:TextInput id="textOne" text="This is a test" />
<mx:Button id="buttonOne" label="Click Me" click="textOne.text='Testing 1-2-3'" />

在这个相当简单的示例中，很明显按钮的单击处理程序中的“textOne”引用了 id 为“textOne”的 TextInput。在下面的示例中，这一点变得不太明显：

<mx:Button id="buttonTwo" label="Change Tab" click="tabNav.selectedChild=newState" />

这里一点也不明显，“newState”指的是 ID 为“tabNav”的 TabNavigator 上下文中 ID 为“newState”的 INavigationContent 实例。

如果我们在 fx:Script 块中执行此操作，或者在外部 AS 类文件中执行此操作，情况会变得更糟（更好）。

public function buttonClickHandler(event:FlexEvent):void {
    tabNav.selectedChild = newState;
}

在这个 AS 类文件中，我们没有声明 tabNav 或 newState，因此，乍一看，我们希望解析器会抱怨。但事实并非如此，因为这些 id 被自动声明为公共属性。

我的意思是，我感觉应该制定一个约定，使这些公共属性的来源更加明显。类似

id="mxTabNav"

或

id="TXTMyTextInput"

可能只是使用下划线

id="my_text_input"

在 Flash 开发中，我们很多人都为（自动）声明的阶段实例（例如“mcMyTabBar”或“navMC”或“playPauseBTN”）执行此操作。

我正在寻找 Flex 社区对此的意见。我只是想太多了吗？我读过的有关该主题的所有相关样式指南和最佳实践文档都只是说“对 ids 使用驼峰命名法，并确保 id 属性是第一个属性”。

你怎么看？

Answer 1

我的看法是，这并不是什么大不了的事。

我的所有组件都被封装（尽可能多），我什至不给 MXML 中的元素提供 ID，除非我真的必须这样做（即模块后面的代码中的某些内容正在引用它）。

我宁愿让一个类通过

myComponent.foo(bar);

函数在 myFooComponent 上设置文本

来与我的组件交互，而不是

myComponent.myFooComponent.text = bar;

如果您根本不引用 MXML 文件，您可以更进一步。我们有用 AS 编写的 View 类，它们都扩展了 Group。在他们的 createChildren 函数中，我们添加了用 MXML 文件编写的组件。

这意味着没有任何东西直接针对 MXML 文件（除非它们开始通过显示列表进行搜索，这会让人感到很紧张），并且 View 类完全封装了 View 对象。

我们甚至更进一步，只通过接口引用视图类，因此我们可以非常轻松地实现视图的多个实现（例如针对客户特定的更改）。

Answer 2

我建议使用“目的和类名”作为 id“”。例如：

printButton, loggerTextArea, resultsDataGrid, etc

对于事件处理程序，使用“on”模式。例如：

onPrintButtonClick(event:MouseEvent):void
onLoggerTextAreaChange(event:Event):void
onResultsDataGridSelect(event:Event):void

1. 因为它以“on”开头，所以很明显该方法是事件处理程序
2. 它在处理程序名称中具有组件名称 - 现在很清楚谁触发了事件
3. 它具有有关事件类型的信息 - 单击、更改、选择...所以它很清楚这是一个什么样的事件...