На текущий момент большинство web-приложений состоят из большого числа библиотек, виджетов и сниппетов из многих и многих источников. Следует помнить, что код других разработчиков может взаимодействовать с вашим кодом в случае, если происходит подключение обоих их на одной странице. А если вы оперируете глобальными переменными, то это и вовсе небезопасно.
Возьмем, в качестве примера, форум Ext JS, который использует три совершенно различных набора скриптов, созданных разными производителями: Ext JS используется нами для расширения функционала, Google Analytics для отслеживания использования сайта плюс обычные скрипты форума vBulletin. На рисунке представлено каким образом весь этот код из различных источников включается в тело страницы. Вообразите себе количество возможных противоречий с еще большим ростом подключаемых файлов.
Если взглянуть на закладку DOM отладчика Firebug, можно увидеть сотни переменных контекста window, созданных подключенными скриптами. В тоже самое время Ext JS объединяет все свои классы в едином пространстве имен Ext и далее организует их в виде отдельных пакетов.
Когда вы пишете собственный срипт, вам следует помещать все свои классы и синглтоны (singletone) в некие пространства имен чтобы предотвратить противоречия с кодом других разработчиков. Термин «пространство имен» определяется в Википедии (EN, RU) следующим образом: «…абстрактный контейнер предоставляющий контекст для содержащихся в нем элементов (имена, термины или слова) и позволяющий предотвратить возникновение неоднозначностей в случае существования элементов с одинаковыми именами…».
Пространства имен это важный инструмент разработчика, гарантирующий невозможность перезаписи одного кода другим. Ведь если иной разработчик определит переменную с таким же, как у вас именем, то существовавшее до этого определение будет перезаписано. Последний подключенный, в таком случае, фрагмент кода будет всегда одерживать верх.
Так как JavaScript является языком с функциональными областями видимости*, то создание функции или/и переменной не «обернутых» в функцию приводит к появлению их в глобальной области видимости (в контексте window). Чтобы предотвратить это разработчики помещают свои классы в объекты.
* — вероятно, автор имеет ввиду создание различных областей видимости, что достижимо в этом языке лишь с помощью функций (прим. пер.)
Без Ext JS вы можете создать пространство имен следующим образом:
Объект Ext предоставляет метод Ext.namespace (или его шоткат Ext.ns), который проверяет создаваемое пространство имен на существование и создает его, если такового еще нет. Сначала следует определить первоначальный уровень пространства, а затем можно создавать различные подуровни-пакеты. Например, создадим пространство имен App и входящие в него пакеты form и data:
Используемый в web-приложениях на стороне клиента код JavaScript становится все более сложным и сложным. Поэтому важность правильной организация совместной работы вашего кода и кода третьих сторон также вырастает. Использование пространств имен гарантирует защиту вашему коду от перезаписи другим, находящимся в глобальной области видимости, кодом.
Автор оригинала: Aaron Conran
Оригинал статьи: Use Namespaces to organize your JavaScript code
Данный хабратопик является кросс-постом из моего блога.
Внимание! После публикации мной перевода статьи Джозефа Сакалоса (Jozef Sakalos) «Создание сложного приложения в Ext», он связался со мной и попросил передать хабрапользователям следующее: «Я в меру своих знаний русского языка просмотрел комментарии по переводу и готов ответить на любые связанный со статьей вопросы в моем блоге в соответствующей теме. Единственная просьба — формулируйте вопросы на русском коротко, пожалуйста, чтобы мне было легче их понять.»
Почему необходимо использовать пространства имен?
Возьмем, в качестве примера, форум Ext JS, который использует три совершенно различных набора скриптов, созданных разными производителями: Ext JS используется нами для расширения функционала, Google Analytics для отслеживания использования сайта плюс обычные скрипты форума vBulletin. На рисунке представлено каким образом весь этот код из различных источников включается в тело страницы. Вообразите себе количество возможных противоречий с еще большим ростом подключаемых файлов.
Если взглянуть на закладку DOM отладчика Firebug, можно увидеть сотни переменных контекста window, созданных подключенными скриптами. В тоже самое время Ext JS объединяет все свои классы в едином пространстве имен Ext и далее организует их в виде отдельных пакетов.
Когда вы пишете собственный срипт, вам следует помещать все свои классы и синглтоны (singletone) в некие пространства имен чтобы предотвратить противоречия с кодом других разработчиков. Термин «пространство имен» определяется в Википедии (EN, RU) следующим образом: «…абстрактный контейнер предоставляющий контекст для содержащихся в нем элементов (имена, термины или слова) и позволяющий предотвратить возникновение неоднозначностей в случае существования элементов с одинаковыми именами…».
Пространства имен это важный инструмент разработчика, гарантирующий невозможность перезаписи одного кода другим. Ведь если иной разработчик определит переменную с таким же, как у вас именем, то существовавшее до этого определение будет перезаписано. Последний подключенный, в таком случае, фрагмент кода будет всегда одерживать верх.
Так как JavaScript является языком с функциональными областями видимости*, то создание функции или/и переменной не «обернутых» в функцию приводит к появлению их в глобальной области видимости (в контексте window). Чтобы предотвратить это разработчики помещают свои классы в объекты.
* — вероятно, автор имеет ввиду создание различных областей видимости, что достижимо в этом языке лишь с помощью функций (прим. пер.)
Пространства имен без Ext JS
Без Ext JS вы можете создать пространство имен следующим образом:
if (!App) App = {};
if (!App.form) App.form = {};
if (!App.data) App.data = {};
Ext.namespace
Объект Ext предоставляет метод Ext.namespace (или его шоткат Ext.ns), который проверяет создаваемое пространство имен на существование и создает его, если такового еще нет. Сначала следует определить первоначальный уровень пространства, а затем можно создавать различные подуровни-пакеты. Например, создадим пространство имен App и входящие в него пакеты form и data:
/* Ext.namespace создаст объекты с переданными именами, если они еще не существуют */
Ext.namespace('App', 'App.form', 'App.data');
/* Теперь можно определять новый класс, например SampleForm, внутри пакета App.form */
App.form.SampleForm = Ext.extend(Ext.form.FormPanel, {
initComponent: function() {
/* код настройки компонента */
App.form.SampleForm.superclass.call(this);
}
});
/* Определение MySingleton внутри пакета App.data */
App.data.MySingleton = function() {
return {
sampleStaticMethod: Ext.emptyFn
};
}();
В завершение
Используемый в web-приложениях на стороне клиента код JavaScript становится все более сложным и сложным. Поэтому важность правильной организация совместной работы вашего кода и кода третьих сторон также вырастает. Использование пространств имен гарантирует защиту вашему коду от перезаписи другим, находящимся в глобальной области видимости, кодом.
От переводчика
Автор оригинала: Aaron Conran
Оригинал статьи: Use Namespaces to organize your JavaScript code
Данный хабратопик является кросс-постом из моего блога.
Внимание! После публикации мной перевода статьи Джозефа Сакалоса (Jozef Sakalos) «Создание сложного приложения в Ext», он связался со мной и попросил передать хабрапользователям следующее: «Я в меру своих знаний русского языка просмотрел комментарии по переводу и готов ответить на любые связанный со статьей вопросы в моем блоге в соответствующей теме. Единственная просьба — формулируйте вопросы на русском коротко, пожалуйста, чтобы мне было легче их понять.»
