Почему необходимо использовать пространства имен?

Возьмем, в качестве примера, форум 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

Маленькая демка поможет ответить на вопрос о необходимости вчитываться в дальнейшее.

Synopsis

Так сложилось исторически, что управляющим элементом по выбору локации (будем пользоваться этим словом для определения месторасположения, местонахождения и иного) является некоторое количество взаимосвязанных списков <select>, позволяющих последовательно уточнять локацию часть за частью. Выглядеть это может примерно следующим образом. Контрол в сумме удобен, малопротиворечив, но несколько устарел. Вот первые, бросающиеся в глаза, минусы решения:

• popup окно для донесения до посетителя всего контрола;
• отсутствие кеширования данных селектов;
• слабая расширяемость и гибкость — любой функционал необходимо реализовывать самостоятельно.

Что необходимо получить

В одном из проектов мне понадобилось обойти всё вышеперечисленное и ко всему прочему соблюсти следующее:

• window based дизайн — ресурс интенсивно редактируется и интерфейс решено было сделать оконным;
• т. к. страница могла не перезагружаться при работе на ней часами, то вопрос кеширования данных стоит очень остро;
• необходимо не только позволять выбирать локации, но и верно отображать их, в такой, например, ситуации как редактирование, когда все селекты уже означены, а соответствующие списки в них уже загружены.

Инструментарий

Нам потребуется:

• Zend Framework;
• ExtJS JavaScript Library;
• Класс Application_Db_Table_Nestedset, описанный в предыдущей статье.

Использование ExtJS обусловлено требованием №1 — интерфейс window based. Только этот фреймворк способен был справиться со всеми требованиями, которые были предъявлены к процессу работы с данными.

ZF и базирующийся на его составляющих Application_Db_Table_Nestedset это ответ на вопрос стандартизации кода, ответ в ряде мест противоречивый, но все же ответ.

кстати:

данные ZF-элементы дизайна контрола можно исключить и заменить на что-либо более привычное буквально в течении получаса.

Контрол в действии

Использование, благодаря мастерству и прозорливости разработчиков ExtJS, практически ничем не отличается от использования стандартных компонент этого пакета — создать и применить Ext.ux.locationSelect также легко как и создать обычную панель.

Подключение

Подключение реализуется в обычном порядке. Если ExtJS уже используется, то необходимо подключить только само расширение:

<head>
    <script type="text/javascript" src="/lib/ext/adapter/ext/ext-base.js"></script>
    <script type="text/javascript" src="/lib/ext/ext-all.js"></script>
    <script type="text/javascript" src="/lib/ext/ux/locationSelect.js"></script>
    <link href="/lib/ext/resources/css/ext-all.css" rel="stylesheet" type="text/css" />
</head>

для галочки:

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

Конфигурирование и создание

Ввиду того, что контрол расширяет Ext.form.FieldSet, то видеть себя он предполагает в поле Ext.FormPanel, однако это необязательное требование.

важно:

подробнейшее описание API, конфигураций и немного примеров по каждому из контролов можно обнаружить в ExtJS API Documentation в соответствующей части дерева компонент, пакетов и классов.

Таким образом включить контрол в форму можно простым добавлением его конфигурационного объекта в items формы:

var myForm = new Ext.form.FormPanel({
    items: [{
        xtype: 'locationselect',
        url: '/someURL',
        prefix: 'some_location_',
        title: 'someFieldSetTitle',
        valueNotFoundText: 'Не важно',
        validator: function(){/*some js-code*/}
        autoHeight: true
    }]
});

Нестандартными конфигурационными полями являются:

• url — адрес куда хранилища контрола будут обращаться за списками частей локаций (страны, регионы и города), по этому же адресу будет отправляться запрос на полную единовременную загрузку локации целиком. Например, Россия | Рязанская обл. | Рязань;
• prefix — префикс имен переменных в которых будут сохранены ID частей локации. Для случая выше при сабмите контрол «сгенерирует» и отправит на сервер переменные _some_location_country, _some_location_region, _some_location_city;
• valueNotFoundText — значение этого поля будет присвоено одноименному конфигурационному полю всех Ext.form.ComboBox контрола;
• validator — функция будет вызываться при событии выбора любой части локации и позволит обязать, например, к указанию локации полностью.

о незаметном:

обратите внимание на символ подчеркивания в именах генерируемых по префиксу переменных. Дело в том, что комбобокс в ExtJS реализации состоит из двух полей ввода — одно из которых и отправляет значение при сабмите формы т.е. приходится генерировать два похожих имени для каждого комбобокса.

Все остальные поля — наследие конфигурации суперкласса.

Загрузка локации целиком

Существуют задачи когда необходимо позволить выбирать локацию и при этом начать выбор с той, что уже установлена — редактирование анкетных данных, оформление переезда и прочее.

Для этой цели контрол имеет метод loadLocation (), который принимает конфигурационный объект формата {country: integer, region: integer, city: integer}. При его вызове будет произведено обращение по url, указанном при создании, с передачей параметров локации. Если вернувшиеся данные соответствуют допустимому формату, то в соответствующие комбобоксы будут загружены списки с данными, а те части локации, которые были заданы в конфигурационном объекте будут выбраны.

Серверная часть

Так как контрол подкачивает данные с помощью AJAX, необходимо «договориться» о протоколе общения его с сервером. Здесь имеется развилка:

1. При выборе какой-либо одной части локации посредством комбобокса контрол «расчитывает» на один массив со значениями для следующего комбобокса в json-формате {rows: [{id: numeric, name: string}, ...]};
2. При полной загрузке локации контролу необходимы массивы для двух последних комбобоксов единовременно в json-формате {rows: {region: [{id: numeric, name: string}, ...], city: [{id: numeric, name: string}, ...]}}.

Мне было удобнее реализовать обе подгрузки в одном действии locationSelectGetSublocations () контроллера AjaxController.

public function locationSelectGetSublocationsAction() {
        $this->_helper->viewRenderer->setNoRender();
        $filter = new Zend_Filter_Digits();
        $location = new Location();
        if ($this->getRequest()->getParam('country', 0) && $this->getRequest()->getParam('region', 0)){
            $countryId = $filter->filter($this->getRequest()->getParam('country', 0));
            $regionId = $filter->filter($this->getRequest()->getParam('region', 0));
            $result = array(
                'region' => $location->getSublocations($countryId),
                'city' => $location->getSublocations($regionId)
            );
            //добавляем опции по умолчанию
            array_unshift($result['region'], array('id' => 0, 'name' => 'Не имеет значения'));
            array_unshift($result['city'], array('id' => 0, 'name' => 'Не имеет значения'));
            echo json_encode(array('rows' => $result));
        } else {
            $id = $filter->filter($this->getRequest()->getParam('parentId', 1));
            $result = $location->getSublocations($id);
            //добавляем опцию по умолчанию
            array_unshift($result, array('id' => 0, 'name' => 'Не имеет значения'));
            echo json_encode(array('rows' => $result));
        }
    }

на заметку:

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

Белым пятном действия является класс Location — модель таблицы location. Это ничто иное как наследник класса Application_Db_Table_Nestedset о котором велась речь в предыдущей статье. Код модели имеет вид:

class Location extends Application_Db_Table_Nestedset{

    protected $_name = 'location';
    protected $_primary = 'id';
    /**
     *  Return child locations of location
     *
     * @param integer parent location id
     * @return array location items
     */
    public function getSublocations($id){
        $result = array();
        foreach ($this->getChildren($id) as $row)
            $result[] = array('id' => $row['id'], 'name' => $row['name']);
        return $result;
    }
}

Таблица данных локаций

Таблицу локаций было решено вынести в отдельный пункт из-за самой её сути. В свое время пришлось попотеть, чтобы найти в Сети довольно полные данные по странам, регионам и городам. Теперь, когда эта задача решена можно скачать порядка 20к объектов одним кликом.

Локации упорядочены и собраны в одной таблице по схеме Вложенных Множеств. Лично мне кажется, что эта схема является очень удачной для такого рода задач:

• данные очень редко изменяются, но часто выбираются;
• нет многих таблиц данных и таблиц связей между ними.

Ресурсы

• Ext.ux.locationSelect.js (trunk/ux)Ext.ux.locationSelect.js (trunk) UTF-8