Соглашения об именовании свойств Flex + MXML и рекомендации - PullRequest
Новая
       2

Соглашения об именовании свойств Flex + MXML и рекомендации

1 голос
/ 03 ноября 2010

Поскольку в пространствах имен существует так много потенциального загрязнения, особенно с помощью анализатора, который автоматически объявляет любой компонент MXML с идентификатором общедоступным с использованием этого идентификатора, я считаю опасным использование только camelCase для идентификаторов элементов MXML.

Например: 

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

В этом довольно тривиальном примере довольно ясно, что «textOne» в обработчике нажатия кнопки ссылается на TextInput с идентификатором «textOne».Это становится менее очевидным в следующем примере: 

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

Здесь совершенно не очевидно, что «newState» ссылается на экземпляр INavigationContent с идентификатором «newState» в контексте TabNavigator с идентификатором «tabNav ".

Это стало бы еще менее понятным, если бы мы делали это в блоке fx: Script или хуже (лучше) во внешнем файле класса AS. 

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

Нигде вв этом файле класса AS мы объявили tabNav или newState, и поэтому, на первый взгляд, мы ожидаем, что парсер пожалуется.Но это не потому, что эти идентификаторы автоматически объявляются как открытые свойства.

Я имею в виду, что чувствует для меня, что мы должны разработать соглашение, которое делает более очевидным, гдеэти публичные свойства приходят из.Что-то вроде 

id="mxTabNav"

или 

id="TXTMyTextInput"

или, может быть, просто используйте подчеркивание 

id="my_text_input"

В разработке Flash многие из нас сделали это для (автоматически) объявленногоЭкземпляры сцены, такие как "mcMyTabBar" или "navMC" или "playPauseBTN".

Я ищу информацию от сообщества Flex по этому поводу.Я просто обдумывал вещи?Во всех связанных с этим Руководствах по стилю и документах о лучших практиках, которые я прочитал по этой теме, просто говорится «используйте camelCase для идентификаторов и убедитесь, что свойство id является первым свойством».

Что вы думаете?

Ответы [ 2 ]

1 голос
/ 03 ноября 2010

Рекомендую использовать пару "цель и имя класса" для идентификатора "".Например: 

printButton, loggerTextArea, resultsDataGrid, etc

, а для обработчиков событий используйте шаблон «on».Например: 

onPrintButtonClick(event:MouseEvent):void
onLoggerTextAreaChange(event:Event):void
onResultsDataGridSelect(event:Event):void
  1. Поскольку он начинается с «on», ясно, что метод является обработчиком события
  2. У него есть имя компонента в имени обработчика - теперь понятно, кто вызывает событие
  3. Он содержит информацию о типе события - Нажмите, Изменить, Выбрать ..., чтобы было понятно, что это за событие ...
1 голос
/ 03 ноября 2010

Я полагаю, что это не так уж и важно.

Все мои компоненты инкапсулированы (насколько это возможно), я даже не даю идентификаторы для элементов в MXML, если мне действительно не нужно (то есть что-то в модуле кода позади ссылается на него).

Я бы предпочел класс, взаимодействующий с моим компонентом через 

myComponent.foo(bar);

, где функция устанавливает текст в myFooComponent

вместо 

myComponent.myFooComponent.text = bar;

Вы можете сделать этот шаг дальше, если вообще не ссылаетесь на файл MXML.У нас есть классы View, написанные на AS, которые расширяют группу.В их функции createChildren мы добавляем компонент, записанный в файле MXML.

Это означает, что ничто не нацеливается непосредственно на файл MXML (если только они не начинают рутиться по списку отображения, который получает быстрый удар по суставам),и класс View полностью инкапсулирует объект View.

Мы даже делаем этот шаг дальше и только когда-либо ссылаемся на классы представления через их интерфейсы, поэтому мы можем иметь несколько реализаций представления (скажем, для пользовательских изменений) оченьлегко.

...