Flex+MXML id property naming conventions / best practices

Question

Since there's so much potential pollution within namespaces, particularly with the parser automatically declaring any MXML component with an id to be publicly-accessible using that ID I'm finding it dangerous to use just camelCase for MXML element ids.

eg:

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

In this rather trivial example, it's pretty clear that "textOne" in the Button's click handler is referring to the TextInput with an id of "textOne". It becomes less obvious in the following example:

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

It's not at all obvious here that "newState" is referring to an INavigationContent instance with an id of "newState" within a TabNavigator context with an id of "tabNav".

This would become even less clear if we were doing this within an fx:Script block, or worse (better) within an external AS class file.

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

Nowhere in this AS class file have we declared tabNav or newState, and so, at first glance, we expect the parser to complain. But it doesn't because these ids are automagically declared as public properties.

What I'm getting at is it feels to me that we should develop a convention that makes it more obvious where these public properties are coming from. Something like

id="mxTabNav"

or

id="TXTMyTextInput"

or maybe just use underscores

id="my_text_input"

In Flash development, a lot of us did this for (automatically) declared stage instances like "mcMyTabBar" or "navMC" or "playPauseBTN".

I'm looking for input from the Flex community about this. Am I just overthinking things? All of the related Style Guides and best practices documents I've read on the topic just say "use camelCase for ids, and make sure the id property is the first property".

What's your take?

Answer 1

My take is that it's not really that big a deal.

All my components are encapsulated (as much as possible), I don't even give IDs to elements in MXML unless I really have to (i.e. something in the code behind module is referencing it).

I'd rather a class interacted with my component via

myComponent.foo(bar);

where the function sets the text on the myFooComponent

rather than

myComponent.myFooComponent.text = bar;

You can take this a step further if you don't reference the MXML file at all. We have View classes written in AS which all extend Group. In their createChildren functions, we add the component written in the MXML file.

This means nothing is targeting the MXML file directly (unless they start rooting through the display list, which gets a swift rap on the knuckles), and the View Class encapsulates the View object completely.

We even take this a step further and only ever reference View Classes by their Interfaces, so we can have multiple implementations of a view (say for customer specific changes) very easily.

Answer 2

I recommend to use couple "purpose and class name" for id "". For example:

printButton, loggerTextArea, resultsDataGrid, etc

and for event handlers use "on" pattern. For example:

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

1. Because it starts with "on" it's clear that the method is event handler
2. It has Component name in handler name - now it's clear who triggers event
3. It has information about event type - Click, Change, Select ... so its clear what kind of event it is...