Задом наперед или начнем с FirePHP

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

Принцип его работы прост как все гениальное — отлавливать все, что подпадает под определенный content-type и выводить силами Firebug. Для разработчика все выглядит прозрачно — выводим отладочную информацию посредством ОО интерфейса предоставляемого серверной частью FirePHP и на дополнительной закладке Firebug видим ее в цвете, а иногда и с салютом. Страничка не искажается.

Наибольшее удовольствие расширение доставит разработчикам, использующим распространенные фреймворки типа CodeIgniter, Symfony или ZendFramework для которых серверная часть расширения написана с соблюдением доктрин и соглашений этих фреймворков. Это значит, что работа по выводу отладочной информации будет более привычной. Например, для ZF backend FirePHP выполнен в виде писателя Zend_Log_Writer_Firebug, передав который в конструктор логгера можно одним махом изменить принцип логирования.

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

Более подробно с расширением можно познакомиться на его официальном сайте www.firephp.org.

BareTail

Эта условно-бесплатная утилита предоставляет возможности отслеживать часто изменяющуюся информацию вроде логов. Это Win32-аналог команды tail из мира *nix — т.е. реализация возможности просмотра файл с конца. Кроме просмотра последних строк файла есть возможность отслеживать содержимое по мере его обновления т.е. в реальном времени, что очень подходит для просмотра логов («если о у вас есть» ©).

BareTail также предоставляет подсветку строк при вхождении в нее некой сигнальной части. К примеру, можно настроить просмотр так, что UPDATE/INSERT запросы будут желтыми, DELETE — красными.

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

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

Кроме BareTail существует полностью функциональная, свободная версия программы с аналогичными BareTail Pro функциями. Это fLogViewer. Однако, как показало использование обеих утилит, в подавляющем большинстве случаев хватает возможностей младшей версии BareTail.

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

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

Вводная

Общеизвестно, что кроме прочего плагины позволяют выполнять некий код до и после действия (action) контроллера. Именно тут и притаилась логическая бомба размеров чуть меньше среднего.

Обычно авторизация (определение возможности выполнения тех или иных деяний в зависимости от прав) помещается в Pre-обработчик:

class Application_Controller_Plugin_Auth extends Zend_Controller_Plugin_Abstract{
    public function preDispatch(Zend_Controller_Request_Abstract $request){
        /*
        ...
        */
    }
}

о выборе:

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

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

Плагин Zend_Controller_Plugin_ErrorHandler, включенный по-умолчанию, регистрирует Post-обработчик и выполняет аналогичные действия с перезаписью значений модуля, контроллера и действия, но в случае возникновения исключений.

об исключениях:

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

Суть

Авторизация, в подавляющем большинстве конфигураций, пропустит нас к несуществующему действию. Однако обработчик ошибок чутко перенаправит на контроллер и действие (по-умолчанию error и error соответственно) по обработке ошибки, что в цикле диспетчеризации опять вызовет проверку авторизации. Если забыть прописать правила на доступ к контроллеру и действию обработки ошибок, мы будем повторно брошены на поиски несуществующего со всеми печальными последствиями: плагин ErrorHandler, почуяв мистический вызов себя второй раз, бросит неотлавливаемое уже никем (ясное дело, их отловом он и занимается) исключение и все будет потеряно.

к слову о перестраховке:

можно обернуть в try...catch вызов Zend_Controller_Front::getInstance() ->dispatch() чтобы ловить неотлавливаемое и там

Вывод и возможные решения

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

Сделать это можно как прописыванием правил Zend_Acl для обработчика ошибок, так и проверкой на существование исключений за обработкой которого мы и обратились к некому контроллеру:

public function preDispatch(Zend_Controller_Request_Abstract $request){
    if ($this->_response->isException()) return;
    /*
    ...
    */
}

$filter = new Zend_Filter_Alnum(true);
Zend_Debug::dump($filter->filter('это странненько - mbstring enabled'));
//string(19) "   mbstring enabled"

$filter = new Zend_Filter_Alnum(true);
Zend_Debug::dump($filter->filter('это странненько - mbstring disabled'));
//string(48) "это странненько  mbstring disabled"

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

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

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

В свое время на phpclub.ru была опубликована статья с неплохим описанием модели, структурой таблиц и примерами. Также Максимом Матюхиным был приведен класс для работы с этой моделью. После возникшей потребности этот класс был переписан под Zend Framework. При «портировании» я просто заставил код немного по другому звучать и добавил некоторую функциональность из PEAR::DB_NestedSet.

Для работы с любыми классами производными от ZF-классов обычно рядом с директорией Zend, содержащей фреймворк, создается директория Application с аналогичной ZF иерархией — в этом случае Zend_Loader сможет подгрузить их в обычном порядке. Этим и обусловлено название класса — Application_Db_Table_Nestedset.

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

Доступ через хранилище или архивом.

PhpED, как и приставка Professional, здесь — ключевые моменты. Если вы используете иной редактор кода, то вам придется иной раз совершать дополнительные действия. Вы также можете создать на основе предлагаемого решения расширение и для своей любимой платформы. Что касается Professional, то только эта версия редактора поддерживает возможность связывания редактора с внешними сриптами, т.е. shell handler.

Предпосылки

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

Сложность первая, главная и последняя — база данных. Мысль, обуславливающая сложность, заключается в том, что необходимо сохранять в хранилище не только код и данные в рабочей копии, но и содержимое базы. Делая «слепок» вашего кода в хранилище, было бы разумным сохранять также и данные базы, иначе не будет возможности вернуться к прошлым правкам полностью — «старый» код будет пытаться работать с «новыми» данными.

Постановка задачи

Немного подумав, приходим к выводу, что нужно реализовать простое, желательно масштабируемое средство, вобравшее в себя все следующие возможности:

1. Выполнение закрепления правки в хранилище;
2. получение дампа базы и помещение его поверх существующего в рабочей копии перед закреплением;
3. обеспечение отката дампа до предыдущего, если закрепление в хранилище не произошло из-за ошибки;
4. комментарии, описывающие правку, должны браться из файла, куда они помещались во время внесения изменений — хорошая практика аккуратной работы;
5. логирование происходящего с выдачей всех диагностических сообщений.

Что необходимо для решения

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

1. Консольный клиент SVN. Вне зависимости от типа установки, если вы уже используете локальную инсталляцию этой системы контроля версий, то такой клиент у вас уже есть — это bin/svn.exe в директории куда вы установили SVN. В ином случае вам необходимо будет его установить, причем совершенно не обязательно для использования в виде интеграции с Apache — просто установить, пусть лежит;
2. дампер баз данных — утилита конкретная каждая для своей СУБД и призванная, в зависимости от своих опций, создавать набор SQL-инструкций полностью отражающих структуру и/или данные базы;
3. PhpED Professional;
4. установленный и настроенный php пятой версии.

Что касается серверов, то трудно представить себе web-разработчика, не имеющего на локальной машине тестовых серверов: http, БД и каких-либо других, по потребностям. Настолько трудно, что и пытаться не будем.

сужаем круг

В случае использования на локальной машине системы подобной denwer ответ на вопрос о СУБД однозначен — MySQL. Вообще, это практически стандарт в области web, таким образом, будем везде подразумевать именно ее. Требование к php пятой версии обусловлена двумя причинами: «давно пора» и «у нас он есть, даже если у нас его нет» о чем чуть позже.

В отношении SVN можно поступить так, как об этом говорилось выше или же установить его полностью для локального использования, о чем уже заходила беседа ранее в статье «Введение в Subversion».

От теории к практике

Для начала следует убедиться, что PhpED установлен с поддержкой как минимум одного php5. Если у вас в директории, куда был установлен редактор, имеется поддиректория с именем php5, то все в порядке. Если это не так, то есть два пути:

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

Настройка путей ОС также необходимый шаг. SVN CLI и mysqldump можно, а в нашем случае и нужно, использовать из любой директории, если внести пути, по которым они расположены, в системную переменную PATH.

Установка и настройка скрипта

Получить скрипт можно двумя путями — скачать архив или взять непосредственно из репозитория (websvn).

Поместите директорию smartyCommit из архива в любое место на жестком диске. Можно порекомендовать размещать расширяющие функциональность PhpED скрипты в поддиректорию scripts редактора, но это — дело вкуса.

В настройках PhpED в разделе Tools/Integration одноименной кнопкой создайте меню, задав любое нравящееся вам имя, например ext. В этом меню мы будем хранить наши собственные срипты. Далее нужно создать подменю, которое и будет командой вызываемой из редактора. После создания команды необходима настройка до состояния отраженного на рисунке ниже, однако обратите внимание, что потребуется указать свой путь к скрипту и выбрать нужный вам хоткей, которые могут быть отличными от тех, что приведены.

Команда будет вызываться для активного проекта (в закладке Workspace он выделен жирным), а значит, показывать команду нужно только в Tools/Scripts, что и отражено в установках опций Show this command *. Скрипт не будет логировать никаких данных, кроме ошибок, но Redirect Output stream to log window нужно выбрать все равно.

Выбор shell-обработчика обусловлен тем, что для выбранной работы нам подходят только SRV и Shell, но SRV открывает всегда новую вкладку со своим выводом в то время как решено было использовать log window.

может все же SRV?

Возможно. Я интенсивно использую log window, однако после рецензирования этой статьи пришел к выводу, что многим людям было бы приятнее работать с выводом в виде html, а это SRV. Кстати, переход можно сделать самостоятельно, наследуя класс и переопределяя методы вывода.

Командная строка содержит путь к выполняющему работу скрипту и ряд макропеременных в виде @varName@ справку по которым можно получить посредством кнопки Show macros. Специальной переменной является переменная вида @Proj(varName)@ значение которой берётся на закладке Custom свойств проекта (Project/Project Properties) (имейте ввиду, что на закладке переменной может и не оказаться). С установкой покончено.

В указании на отправную точку работы — директорию рабочей копии мы будем опираться на проекты PhpED. Чаще всего под некий сайт или работу выделяется отдельное рабочее пространство (Workspace) в котором существует один или несколько проектов.

почему несколько?

Иногда удобно располагать все служебные файлы, библиотеки, настройки выше уровня DocumentRoot, что повышает безопасность. Такой подход сказывается на организации удаленной отладки, что и влияет на количество проектов в рабочем пространстве. Подробнее обо всех способах можно узнать из HOWTO: Set project mapping.

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

Время настроек задачи: имя БД, логины, пароли и другие данные, которые меняются от задачи к задаче. Значения таких опций устанавливается посредством конфигурационного файла, располагающимся в корне рабочей копии и обычно находящимся в игнор-листе SVN. Файл имеет имя peScripts.options.php и представляет собой обычный php-скрипт с одним простым массивом. Пример полного массива приведен ниже, причем все указанные значения являются значениями по умолчанию, как если бы опция отсутствовала в вашем варианте массива.

<?php
$smartyCommit = array(
	'db' => array(
		'host'     => 'localhost',
		'user'     => '',
		'password' => '',
		'name'     => ''  //database name
	),
	'dump' => array(
		'params' => '--allow-keywords --no-create-db --quote-names', //dumper command lines additional params
		'file'   => 'dump.sql' //file where dump will store
	),
	'svn' => array(
		'params'         => '--no-auth-cache',  //svn commit command lines additional params
		'fileLogMessage' => 'logs/commit.message', //file with commit messages. Note: path is _relative_ from svnRoot
		'user'           => '',
		'password'       => '',
		'log'            => 'logs/smartyCommit.log' //file where svn commit log will stored. Note: path is _relative_ from svnRoot
	),
	'dirTmp' => 'c:/windows/temp/'
);
?>

По сути это все. Теперь по хоткею команды будет произведено дампирование базы данных, а затем последующая фиксация всей рабочей копии в хранилище. Если на каком-то этапе произойдет ошибка, то будет произведен откат до состояния как если бы команда вообще не была выполнена.

Если у вас возникли какие-либо проблемы, то проверьте все ли правильно вы сделали по установке и настройке, обращая особое внимание на пути, задаваемые в настройках.

Подводные камни и нюансы

1. Макропеременная @php5@, в отличие от @php@, которая указывает на CLI версию php4, ссылается на CGI вариант. Это следует учитывать, так как в эти версии довольно сильно разнятся;
2. mysqldump читает конфигурационный файл СУБД, если вы указали в нем кодировки, то нет необходимости сообщать о них mysqldump отдельно;
3. если команда расширения PhpED не указана как включаемая в Tools, то она не будет выполняться по выбранному для нее хоткею;
4. означить макропеременную someVar на закладке Custom свойств проекта станет возможно только с использованием @Proj(someVar)@ в командах. Общий принцип — сначала заявите об использовании, затем означьте;
5. если значение макропеременной оставить пустым, то будет передано ее имя;
6. при выполнении длительной операции PhpED выдает соответствующее окошко с прогресс баром. Используйте sleep() для отладки;
7. если в свойствах команды отключено перенаправление потока Output в log window, то даже с активированным перенаправлением потока Error ошибки не будут попадать в log window — возможности писать в это окно не будет вовсе;
8. только Professional версия редактора поддерживает shell и SRV обработчики;
9. конечные слэши в путях к различным объектам можно как указывать, так и опускать — скрипт позаботится об их верном количестве;
10. файл с комментариями для svn commit должен находиться в активном проекте, если вы хотите запускать срипт, находясь на его закладке. Обычно это нечасто at once встречающийся нюанс.

Заключение

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

Данная статья основывается на предыдущей, а также на мысли, что лучший способ что-либо понять — сделать это самому.

Что такое ветвление

Ветвление (branching) SVN — это именно то, что стоит за этим словом: создание ветвей. Ничем большим или меньшим это понятие не обладает.

То чем мы занимались до этого (см. статью «Введение в Subversion»), было движением по единственной координате — времени. Однако представьте себе некий проект, в котором одновременно идет работа по многим направлениям разом, но в неком одном общем. Например, это может быть разработка «ПрограммаХ», когда один отдел работает над известными ошибками, другой занимается разработкой плагинов, а третий работает по главному вектору разработки. Вся работа, проделываемая ими, сказывается на разнице «ПрограммаХ» от самой себя, например, в какой-то момент времени в основной версии программы содержится некая ошибка, в то время как в версии отдела по борьбе с ошибками ее уже нет.

краткий итог:

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

Зачем нужны ветки

Представьте себе, что вам поручили оптимизировать схему подключения к основной программе плагинов. Или другой случай — в вашей среде разработки принято делать технический релиз в субботу вечером, чтобы группа по работе над качеством могла приступить к своему делу в понедельник. Как бы то ни было, из-за того, что потребуется внести много мешающих основной линии разработки изменений, самое эффективное решение — создание отдельной ветки, в то время как в основной не прекращает кипеть работа по своим графикам. Суть в примерах только в том, что они порождают различные «типы» веток. Таких несколько:

• Функциональные ветки;
• Ветки релизов;
• Метки.

это принципиально:

Тип ветки — условное понятие. С точки зрения SVN любая ветка — это обычная директория в хранилище. То, что делает эту директорию тем или иным типом ветки находится в вашем ее восприятии. Это порой путает, но является исключительно простым по сути, надо только запомнить.

Именно наличие нескольких типов веток и объясняют странную на первый взгляд структуру хранилища по умолчанию:

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

Функциональные ветки

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

Метки

Может возникнуть вопрос о причине вынесения меток в отдельную директорию. Дело в том, что обычно это просто ссылка на ту или иную правку какой-либо ветки. Почему ссылка? Вспомните, что говорилось о «дельте данных» в предыдущей статье. Точно такая же схема используется и при создании ветки, а в случае метки — копии ветки. Т.к. при создании метки ничего нового не появляется «дельта» по сути равна нулю и создаются просто ссылки на объекты ветки из которых создается метка. Таким образом, метки уменьшают многословность и неопределенность вида «ветка branches/version_3.14@364» сводя ее к примерно следующему «tags/october» — октябрьский релиз. Данные при этом не копируются, хранилище не растет вширь, навигация по множеству релизов упрощается. Совокупность меток, релизов, а при необходимости и функциональных веток, помогает организовать работу для решения задачи из второго примера в начале этой главы.

краткий итог:

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

Использование веток

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

Пусть нашей целью будет обновление WordPress v2.2.3 на v2.3.0. Также предположим, что в нашем распоряжении имеется хранилище, расположенное по адресу http://127.0.0.1/svn/web-dev причем со структурой директорий как это рассматривалось выше. Главная ветка разработки с номером правки 35 содержит WordPress v2.2.3.

уступка реальности:

для тех, кто имеет дело с WordPress не секрет, что переход на v2.3.0 сопряжен также и с изменением БД ввиду введения в понятие движка меток-тегов. Также не во всех случаях обновление возможно простым «копированием поверх». Для упрощения примера опустим эти тонкости. Вопрос синхронного закрепления в хранилище, как файлов, так и содержимого БД — предмет дальнейшей статьи «smarty commit».

Таким образом, начальная картина хранилища и ее временная диаграмма будут иметь вид:

Каковы будут действия для выполнения поставленной задачи:

1. Создадим метку tags/v223 для текущего состояния trunk — по сути именованный backup;
2. Создадим ветку branches/v230 на основе trunk — поле деятельности, в котором и будет происходить файловые операции по обновлению WordPress;
3. Выполним все операции, требующиеся для обновления;
4. Сольем trunk и branches/v230 чтобы в будущем вести в trunk работу над v2.3.0.

Создание

Создание ветки осуществляется обычным копированием того, что будет ответвлено (обычно это trunk) в ту директорию хранилища, которая соответствует типу создаваемой ветки.

чтобы никто не ошибся:

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

Обратимся к нашему примеру, где для начала необходимо создать метку. Откройте хранилище http://127.0.0.1/svn/web-dev посредством пункта контекстного меню TortoiseSVN→Repo-browser на любой директории любого локального диска. Выделите директорию trunk и для команды контекстного меню Copy to… задайте адрес http://127.0.0.1/svn/web-dev/tags/v223. Копирование произойдет очень быстро т.к., по сути, никакие данные не копируются, о чем уже говорилось выше. Ветка успешно создана, а о том, что это метка говорит нам только ее месторасположение.

на заметку:

При каждом создании ветки создается новая правка, именно поэтому в нашем примере номер правки с которой метка начинает жить самостоятельно — 36.

Для того чтобы выполнить второй пункт нашего алгоритма повторите действия по созданию ветки (сначала, если вы поспешили закрыть браузер хранилища), но конечной целью укажите branches/v230.

можно иначе:

клиент TortoiseSVN предоставляет альтернативный способ ветвления посредством команды TortoiseSVN→Branch/Tag… Смысл у нее тот же самый, все изменения также производятся на стороне хранилища без передачи данных клиенту, и команда, по сути, является просто быстрым способом создания ветки без обозревания хранилища.

Мы добились некоторых результатов, которые можно было бы отразить следующим образом:

краткий итог:

Ветка — копия чего-либо. Но технически копия «легкая». Это означает, что при ее создании создается новая правка, все объекты которой указывают (ссылаются) на объекты предыдущей правки. Настоящее копирование произойдет только при изменении чего-либо в ветке. Все это напоминает обычное закрепление изменений и по сути таковым и является, с той лишь разницей, что добавляется дополнительная информация об истории.

Изменение

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

Теперь, когда у нас есть новая ветка branches/v230 мы можем поступить по-разному:

1. Сделать checkout ее содержимого в какую-то директорию и начать с ней работать;
2. Переключить нашу, уже существующую рабочую копию, которая указывает на trunk так, чтобы она стала отражать содержимое branches/v230;
3. Скопировать рабочую копию trunk в какую-нибудь директорию и поступить с ней как это описано в предыдущем пункте.

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

чтобы никто не забыл:

Мы исходим из web-ориентированности повествования. У нас тут всякие Apache и прочие www.

Третий вариант является частным случаем второго, который, в свою очередь, будет работать максимально эффективно при следующих условиях:

• Нет необходимости работать одновременно в нескольких рабочих копиях разных ветвей;
• Хранилище расположено удаленно;
• Переключение предполагается произвести между trunk и только что созданной на ее основе ветки.

Первый пункт обуславливает меньшее количество телодвижений — не надо ничего создавать, выгружать, конфигурировать, перезагружать (если вы используете не denwer) и прочее. Последний пункт экономит наш трафик при условии выполнении второго пункта и просто время, если это не так. Дело во все той же «дельте» — при создании рабочей копии мы передали бы некоторую часть хранилища полностью, в то время как при переключении — только разницу, которая в этом частном случае теоретически равна нулю.

о вечном:

В теории все замечательно, однако на практике немного информации все же передается, но по сравнению с checkout ее объем пренебрежительно мал.

Так как в способе первом ничего интересного нет, попытаемся освоить другой метод. Освоение будет заключаться в выполнении над рабочей копией trunk команды TortoiseSVN→Switch… с указанием того на что мы будем переключаться branches/v230. После завершения операции рабочая копия будет представлять собой содержимое этой самой ветки, update, commit и некоторые прочие операции по умолчанию будут работать уже не с trunk, а с branches/v230. В общем, произошло нечто ожидаемое — переключение на другую ветку разработки без утомительных выгрузок в новую рабочую копию и прочего. Теперь можно работать, как это делалось прежде. Для нашего примера это все необходимые действия по обновлению WordPress — копирование поверх обновленных файлов движка, проверке все ли в порядке, доводка напильником и прочими подручными средствами. Естественно, что в ходе этих действий можно и нужно использовать всю мощь SVN: update, commit, revert и прочее.

если подумать:

Команды switch и update очень похожи — обе изменяют рабочую копию на основе анализа хранилища. На самом деле update является частным случаем switch, которая может сравнивать и изменять текущую рабочую копию с различными ветками в хранилище. Это более гибкий и мощный инструмент. Оправданием существования update может послужить то, что это менее гибкий и мощный инструмент.

Для того чтобы продолжить линию нашего примера представим, что в ходе изменений было создано 7 правок и мы остановились на правке №44:

Копирование изменений между ветками

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

То как часто это следует делать, необходимо ли делать вовсе и прочие вопросы, связанные с этой операцией решаются исходя из типа ветки, внутренней политики разработки и чувства меры. Например, самый распространенный случай, когда имеется главная ветка разработки и несколько функциональных ветвей. Тогда если в ветвях делаются изменения по каким-то причинам выходящие за рамки целей создания этих ветвей, их необходимо копировать в главную ветку разработки как можно скорее. Примером такого рода изменений может служить обнаруженная и исправленная ошибка, в то время как ветки не предназначались для их отлова и исправления. Как видно существует довольно много «если» и вопрос своевременности копирования изменений из ветки в ветку по праву можно считать тонким.

из чувства справедливости:

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

Копирование части изменений

Пусть в ходе работ по обновлению было выяснено, что в обеих ветках (trunk и branches/v230) в файле www/wp-config.php, который не был перезаписан обновлением, была замечена ошибка. Таким образом, ошибка содержится в обеих ветках. Предположим, что мы справили ее в текущей на данный момент branches/v230, и закрепили исправление в правке №44. Задача состоит в копировании исправления в tags/v223.

Предыдущая мысль — типичный пример засады, которые встречаются на пути не только начинающих пользователей SVN. Ошибка заключается в предании забвению факта, что все правки любой из веток — фотографии, слепки всего дерева хранилища на какой-то момент времени, а значит, мы не можем изменить уже закрепленные правки — tags/v223 «потеряна» для нас. К тому же эта метка, как и другие ветки, живет отдельно и изменения в ней не будут видны, например пользователям trunk.

Следует поступить по следующей схеме:

• Портировать изменения в самую общую ветвь — trunk, обязательно указав в комментарии, что это порт и описав его суть, чтобы для людей пользующихся одновременно trunk и branches/v230 не поставил в тупик неожиданный могущий возникнуть конфликт;
• Удалить tags/v223 или оставить ее на месте;
• В зависимости от выбранного действия над tags/v223 нужно или портировать в нее изменения из trunk, или создать на основе trunk новую метку, назвав ее, например, tags/v223_patched1 с комментарием о сути патча.

Теперь у нас полный порядок в логике и хоть сказанное выше звучит устрашающе, но на практике все очень просто.

Портирование изменений осуществляет консольная команда svn merge или ее представитель TortoiseSVN→Merge…. Команда принимает адреса сравниваемых деревьев и рабочую копию, к которой разница между деревьями будет применена в виде локальных (!!!) изменений. Потом их можно будет закрепить или отменить.

Ветви, которые участвуют в портировании изменений, дадут адреса деревьев, а направление ответит на вопрос к рабочей копии какой ветки применять разницу. В нашем примере from — http://127.0.0.1/svn/branches/v230/www/wp-config.php, to — также http://127.0.0.1/svn/branches/v230/www/wp-config.php, а рабочая копия для ветки trunk.

обратите внимание:

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

Адреса деревьев будут не полными без указания номеров правок. Это уточняющая координата. Обратимся к логике: мы условились, что исправления, которые мы должны портировать, закреплены в правке №44, а значит, в правке №43 их не было. Следует вывод, что диапазон номеров правок будет 43−44. Это все необходимые данные.

чтобы не ошибиться:

Рекомендуется запускать тестовое слияние посредством кнопки «dry run» перед тем как запустить его по-настоящему.

Теперь исправление ошибки находится в ветке trunk под правкой №45, но оно никак не отражено в метке tags/v223. Логично хранить все изменения в одном месте, значит, ничего удалять не будем, а портируем только что портированные в trunk изменения и туда. В этом случае адрес дерева from будет таким же, как и в предыдущем портировании, to — аналогично. Диапазон номеров правок также останется без изменений. Изменится лишь рабочая копия, которая должна будет отражать состояние tags/v223. В этом нам поможет уже известная нам TortoiseSVN→Switch…. Теперь все логически верно: все состояния, на которые можно откатиться при неудачном обновлении WordPress до v2.3.0, у нас находятся в tags/v223, причем с возможностью выбора момента отката — до исправления ошибки (правка №36) и после ее портирования (правка №46).

Все изменения, произошедшие с хранилищем, можно отобразить следующей диаграммой, где жирная линия означает портирование изменение с последующим закреплением:

Обратите внимание на жирную линию со штрихом. Это альтернативный способ портирования изменений в tags/v223 достигаемый при параметрах from и to равными http://127.0.0.1/svn/trunk/www/wp-config.php, с диапазоном правок 35−45. Аналогичный результат даст команда и для правок 35−44 при неизменном адресе сравниваемых деревьев. Это обусловлено тождественностью правок 44 и 45. Как видите, результата можно достигнуть множеством путей. Однакое необходимо заметить, что эти способы работают только в конкретном случае примера, когда между правками 35 и 37 не было изменений trunk, что помешало бы использованию альтернативных способов, но об этом ниже.

краткий итог:

При слиянии необходимо всегда руководствоваться логикой и запомнить, что merge выполняется для двух деревьев хранилища заданных адресами и диапазоном правок, а разница всегда применяется к рабочей копии или части ее, если команда была выбрана не для всей копии. Никакие изменения в хранилище при этом не вносятся — вам нужно будет сделать это самостоятельно позже обычным commit, если потребуется. Сломать что-либо слиянием очень сложно, хотя запутаться есть где. Затем и логика.

Слияние веток полностью

Мы только что закончили все операции по обновлению WordPress до v2.3.0 и остались довольными качеством работы. Время за слиянием функциональной ветки branches/v230 в основную линию разработки trunk.

Опять прибегаем к логике: необходимо сравнить trunk@35 и branches/v230@44 чтобы получить разницу которую надо применить к trunk. Для нашего конкретного случая это сработает, все верно. Но это ошибочный путь, не думайте в таком ключе. Представьте себе, что кто-то из ваших товарищей все это время работал над trunk и вносил туда изменения. Тогда при попытке вычислить разницу между trunk@35 и branches/v230@44 вы засечете и его изменения, которые, пересекаясь с вашими, могут дать непредсказуемые результаты. Гораздо легче и безопаснее сравнивать branches/v230@37 и branches/v230@44, что оправдано и логически: взять все изменения в ветке branches/v230 с момента ее создания до последней правки.

Самое «сложное» — определить начальную правку ветки. Делается это посредством просмотра лога ветки при выбранной опции «stop on copy/rename», что в свою очередь достигается через контекстное меню нужной ветки в repo-browser.

Остальные моменты слияния ничем не отличаются от уже делавшихся нами в предыдущей части этой статьи.

для внимательных:

Можно заметить, что для trunk часть изменений применяется дважды, что объясняется неспособностью автора придумать более элегантный пример. Однако ничего страшного в этом двойном применении нет т. к. второго, по сути, не произойдет — в этом месте «дельта» изменений и рабочей копии будет равна нулю.

Теперь ветку branches/v230 можно удалить или оставить и создать метку tags/v230, что уже не является сложной задачей.

Подводные камни и нюансы

1. Ветки — простые копии;
2. Можно переключать с ветки на ветку не только всю рабочую копию, но и один единственный файл или директорию. Все, что необходимо — знать, что только с ними будет вестись работа. Также имеется возможность переключаться и на любую правку ветки;
3. Обязательно комментируйте портирование изменений вплоть до номеров правок — это поможет вам в ряде случаев. Например, предположим, что branches/v230 не была удалена после полного слияния с trunk и в ней продолжилась работа, которая привела к появлению правок 48−55. Пусть необходимо также портировать эти изменения в trunk. В этом случае по комментариям в логе хранилища легче всего определить, что первая волна изменений охватывала правки 37−44 и была закреплена в правке 47. Значит, вторая волна должна охватывать правки 48−55 и никак не 37−50, что приведет к захвату изменений первой волны дважды;
4. Никто не обязывает вас делать хранилище со структурой, о которой говорилось в этой статье. Организация хранилища — личное дело каждого. Однако стоит помнить, что вещи проверенные временем заслуживают внимания;
5. Совсем не обязательно иметь на локальной машине такую же структуру, как и у хранилища. Может случиться, что у вас на компьютере в один момент времени будет лишь одна рабочая копия, расположенная в неком DocumentRoot некоего сайта и вы будете интенсивно использовать svn switch для доступа к иным местам хранилища. Экономьте свое место на диске и время.

Заключение

Ветки — это просто. Все, что необходимо в работе с ними — логика и четкое понимание происходящего. Ну и практика, конечно. Не опасайтесь их, просто используйте.

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

Нам понадобится Mootools, редактор Flash, чувство меры, руки и непредвзятое отношение ко всему, что будет дальше.

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

Нет нужды перебирать достоинства или недостатки flash. Как в случае со многими технологиями необходимо просто прийти к решению использовать его или отказаться. В этом примере мы решили закрыть глаза на все минусы и применить в качестве фундамента.

Озадачимся созданием анимационного эффекта всплеска от клика на канве страницы с поддержкой полупрозрачности.

следует заметить

Эффект надо бы назвать псевдовсплеском ввиду того, что он не деформирует поверхность как это есть при реальных кругах на воде.

Также необходим механизм выборочного отключения эффекта для различных элементов и их групп.

Эффект в действии

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

В самом простом случае включение эффекта осуществляется подключением pellet.js и созданием объекта эффекта:

<html>
	<head>
	//…
	<script type="text/javascript" src="/js/pellet.js"></script>
	//…
	</head>
	<body>
		<script type="text/javascript">
			var myPellet;
			window.addEvent('domready', function(){
				myPellet = new pellet();
			});
		</script>
	</body>
</html>

Смысл заключается в создании объекта после загрузки всего дерева элементов страницы. Реализуется это силами Mootools в теле обработчика нестандартного события onDomReady. Это все.

Подгонка эффекта

Как изменить цвет всплеска, его размеры, фактуру? Просто откройте pellet.fla и рисуйте. Стоит, однако, помнить, что если вы изменили габариты flash-ролика, то об этом надо сообщить и js-части.

Для того чтобы задать элементы при клике на которых эффект воспроизводиться не будет, используется один из параметров конструктора exclude. Параметр представляет собой строку, где через запятую в синтаксисе CSS перечислены правила для исключаемых элементов.

на заметку

Mootools — правильный «браузер» и поддерживает большинство из всех мыслимых комбинаций селекторов. Обратитесь к шпаргалке по CSS, если хотите узнать о них больше. Это автоматически расширит ваши возможности в исключении элементов из «поля видимости» эффекта.

Немного примеров:

var myPellet = new pellet();
/*
все параметры по умолчанию:
	ролик находится по /flash/pellet.swf
	ширина: 50px
	высота: 50px
	исключаемые элементы: *[disabled], input[type=text], input[type=checkbox], input[type=radiobutton], textarea, select
*/

myBluePellet = new pellet({flash: '/flash/bluePellet.swf'});
/*
ролик находится по /flash/bluePellet.swf
все остальные параметры по умолчанию:
	ширина: 50px
	высота: 50px
	исключаемые элементы: *[disabled], input[type=text], input[type=checkbox], input[type=radiobutton], textarea, select
*/

myCustomPellet = new pellet({flash: '/flash/customPellet.swf', width: 40, height: 40, exclude: '#header, div.blackHole, input[type~=submit]'});
/*
все параметры переопределены:
	ролик находится по /flash/customPellet.swf
	ширина: 40px
	высота: 40px
	исключаемые элементы: #header, div.blackHole, input[type~=submit]
*/

Подводные камни и нюансы

1. Когда начинать? Создание объекта должно произойти только после полной загрузки объектной модели документа. IE, например, имеет дурную привычку выводить сообщение о невозможности загрузить страницу при попытке писать в еще не загрузившийся document.body.
2. IE и фоновое изображение. IE иногда глючит, забывая обновить фоновую картинку после того как всплеск исчез. В этом можно убедиться, кликнув на грани градиентного фона внизу страницы.
3. Linux. В большинстве дистрибутивов Linux и Unix наблюдается отвратительная поддержка прозрачного фона flash-ролика — ее попросту нет. Ужасное зрелище, особенно на темных страницах. Рекомендуется определять тип платформы чтобы не использовать эффект который плохо поддерживается.
   

   примечание

   В Mootools 1.2dev имеется набор свойств Client.Platform который поможет в детектировании платформы. К сожалению, это полезное семейство отсутствует в версии 1.11 которая является стабильной веткой фреймворка.

4. Когда лучше? В случае светлой странички — мелкие цветовые артефакты эффекта заметны менее, да и оттенки видны лучше.
5. Минус. Заключается он в перекрытии собой на время проигрывания всего, что находится под ним. Например, в случае сгруппированных рядом чекбоксов не всегда получится с должной скоростью прощелкать по всем ним — клик будет попадать по «всплеску».

Заключение

В качестве вкусного напоследок будет архив с примерами, исходниками двух «плюх», их swf версиями и самим js-классом. Приятного аппетита чтения.

В этой статье мы поговорим, установим и попытаемся использовать в своих корыстных целях одну из разновидностей СКВ — Subversion. Почему так? Subversion очень популярна среди разработчиков, предоставляется многими хостерами, а возможная тесная интеграция с web-сервером Apache только добавляет ей очков. Чем-то Subversion походит в этом отношении на PHP — также много отличных альтернатив, но…

на заметку

Примечание: не стоит думать, что Subversion это «только под web и для web». Соответствующим образом настроенная эта СКВ подойдет всем кто к ней готов.

Причины использования

Подавляющее большинство разработчиков приходят к СКВ, когда им перестает хватать резервного копирования проекта в виде стека директорий (оставим в стороне случай, когда использование СКВ — требование «свыше», мы все не любим насилие). Кто-то пытается подвести под наименование таких директорий некую систему (к примеру, в виде дат), кто-то хранит описание копий в файлах, кто-то находит решение в соответствующем ПО вроде nnbackup. Однако приходит определенный момент и мысли тянутся к более эффективным решениям — СКВ. Установив одну из них, можно не беспокоиться о создании резервных копий данных — все будет сделано автоматически. Более того, вскоре вы даже забудете о таком явлении как резервирование, вы будете пользоваться широкими возможностями СКВ, не замечая, что создается один backup за другим. И это хорошо.

Также одной из самых распространенных причин применения СКВ может служить командная разработка. В таком случае контроль монопольного редактирования, отслеживание изменений и их слияние являются настоящим кошмаром, если не использовать СКВ.

малый итог

Использование СКВ оправдано как в случае одиночного разработчика, так и для ситуации когда их несколько.

Общая теория

Для начала необходимо усвоить базовые понятия и термины, единые для большинства различных СКВ. Их не много:

• repository (хранилище) — место где СКВ хранит данные, информацию об их изменениях и другую системную информацию;
• checkout — извлечение части или всего содержимого хранилища и создание на их основе рабочей копии;
• working copy (рабочая копия) — слепок хранилища расположенный на локальной машине. Именно рабочая копия подвергается изменениям перед тем как данные будут занесены в хранилище. Рабочая копия содержит также данные о версиях содержащихся в ней файлов. Именно их наличие и определяет, что директория и есть рабочая копия;
• revision (версия, номер правки, правка) — каждый объект в понятиях СКВ имеет версию, номер которой назначается автоматически, если документ изменялся;
• commit (закрепление изменений) — копирование изменений из рабочей копии в хранилище. При этом создается новая правка;
• update (обновление) — операция получения данных из хранилища, если в рабочей копии они устарели;
• merge (слияние) — объединение независимых изменений над одним файлом. Такое происходит, когда в разных правках менялся один и тот же файл.

Также потребуется рассмотреть самые известные реализации СКВ, чтобы знать об их возможностях и недостатках:

• CVS (Concurrent Version System) — система, своими корнями уходящая в далекие 80-е, очень популярна и сейчас. Обладает почти всеми необходимыми инструментами для контроля изменений, сравнения, слияния и устранения конфликтов. Существенным минусом данной реализации является отсутствие контроля версий директорий;
• VSS (MS Visual SourceSafe) — реализация СКВ софтверного гиганта, ориентированная на индивидуальных разработчиков или небольшие их группы. Доступна посредством установки Visual Studio. Имеет старшего брата Visual Studio Team Foundation Server. К недостаткам относится Win32-ориентация;
• SVN (Subversion) — система контроля версий пришедшая на смену CVS и призванная устранить все ее недостатки. Имеет возможность интегрирования с web-сервером Apache, отслеживает версии не только файлов, но и директорий. За каждым объектом в хранилище можно закрепить любую информацию в так называемых свойствах и она также попадет под контроль версий.

Дополнительную информацию о приведенных и других реализациях СКВ можно найти, запросив Google.

малый итог

Даже на первый взгляд видна исключительная аппетитность SVN. Возможно, дело в предвзятом изложении материала, но вероятнее всего, что это законное положение лидера.

Subversion

Будем последовательны — разовьем тему SVN.

Главное преимущество SVN — интеграция с Apache. Это настоящий подарок web-разработчикам — один привычный сервер, известные подходы в обеспечении безопасности, авторизованного доступа и прочего.

замечание

CVS также имеет модуль позволяющий использовать ее с Apache, но он слабо распространен и последний раз обновлялся в далеком 2003 году.

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

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

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

риторика

Надо ли говорить, что SVN также наследует все положительные стороны своего родителя — CVS.

Отличным инструментом, предоставляемым SVN, является команда вычисления разницы, которая может применяться как к отдельным файлам, так и к правкам. Хотите узнать, что было изменено коллегой или левой рукой за вчерашний день? Это просто.

примечание

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

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

Всегда в распоряжении возможность создания веток — самостоятельных линий разработки, начинающихся в точке ветвления и ничем не отличающихся от основной по принципам работы. Это очень удобно, когда требуется внедрить в проект некую функциональность, реализация которой потребует множества правок. Ваши действия будут мешать остальным разработчикам (или вам самим) просто тем, что какое-то продолжительное время не смогут быть завершены. По окончанию работы в ветке изменения, внесенные в проект на ее пути, можно «слить» в основную линию разработки с минимальными усилиями со стороны разработчиков.

Виды установки

Различают три способа установки SVN сказывающиеся на типе доступа к хранилищу:

• Под управлением web-сервера Apache посредством mod_dav_svn;
• В виде самостоятельного сервиса svnserve — небольшого демона, который для связи с клиентами использует собственный протокол;
• Не устанавливать SVN вовсе.

важно

В случае интеграции с Apache возможна установка только для Apache версии 2.x. Это связано с рядом архитектурных особенностей второй ветки сервера. Если вы используете Apache версии 1.x, можно порекомендовать установить Apache версии 2.x в виде второго web-сервера на другом порту.

Сравнение двух первых способов можно видеть в таблице ниже:

Оба вышеописанных варианта подразумевают, что доступ к хранилищам будет предоставляться на основе парадигмы «клиент-сервер». Это частая ситуация когда разработчиков много. Однако нередко нужно развернуть систему контроля версий без подобных сложностей. В таком случае потребуется только клиент — программа необходимая в любом случае. У подхода есть один минус — файловая система, на которой находится хранилище, должна быть локальной.

краткий итог

Если заниматься разработкой web-приложений под управлением Apache, то выбор очевиден — один и привычный сервер. В ином случае целесообразно использовать поставляемое с SVN svnserve. Когда же требуется локальная реализация SVN, без доступа извне, то можно обратить внимание на третий вариант.

Настройка

Так как статья носит web-ориентированный характер, мы коснемся только реализации «SVN через протокол WebDAV» под управлением сервера Apache. Этот способ даст нам следующие преимущества по сравнению с другими:

• Просмотр содержимого последней правки хранилища в браузере — мы все любим ссылки;
• Передаваемые данные могут быть сжаты обычным образом с помощью mod_deflate;
• С помощью скриптов на своем любимом языке можно оперировать данными хранилища.

Условимся использовать в этой статье пути, которые используются мной в повседневности: мне удобно излагать, а вам не привыкать видеть чужие конфиги. Также «сразу» предупреждаю, что разговор будет идти на языке Windows. Извините.

Пусть Apache установлен у нас как это видно на рисунке ниже. Содержимое home — ряд директорий, внутри которых имеется директория www — DocumentRoot соответствующего виртуального хоста.

Вид директорий с которыми мы будем иметь дело

вы заметили?

Файловая организация популярного пакета denwer и используемая в данной статье, пересекаются в home — функции этой директории идентичны и там, и там. Этот факт может помочь для перенесения изложенного материала на рабочее пространство denwer.

Убедимся, что у нас есть, установлено и настроено все необходимое:

• Web-сервер Apache;
• Модуль расширения mod_dav.so;

Брать дистрибутив SVN из-за ОСзависимости лучше с сайта разработчика. Установка не вызывает обычно вопросов, но есть пара нюансов:

• Снимите чекбокс конфигурации модулей с перезапуском Apache — мы все сделаем самостоятельно;
• Не поддавайтесь на уговоры установщика и не редактируйте autoexec.bat. Найти смысл в этой рекомендации также сложно, как и сам файл.

Ссылку на дистрибутив TortoiseSVN, визуального клиента SVN для Windows, можно найти во все том же разделе загрузок. Установка. Игнорирование предложения перезагрузиться.

Конфигурирование Apache. Многие используют комплект denwer, у меня своя сборка триады Apache, PHP, MySQL, есть иные варианты. Объединяет их одно — во всех случаях файл httpd.conf должен существовать. Им и займемся:

• Там где у вас скопление директив загрузки модулей «LoadModule» добавьте еще одну:

  LoadModule dav_svn_module "@SubversionDir@/Subversion/bin/mod_dav_svn.so"

• Убедитесь, что также активна директива загрузки модуля WebDAV, модуль существует, а его загрузка идет до загрузки dav_svn_module:

  LoadModule dav_module modules/mod_dav.so

• Там где вам это кажется уместным, но обязательно в файле httpd.conf создайте описание «директории» для SVN:

  <Location /svn>
  	DAV svn
  	SVNParentPath "d:/www/svn_repository"
  </Location>

Создаем d:\www\svn_repository, перезагружаемся и пытаемся запустить Apache. В случае удачи ничто вас не побеспокоит. Если же что-то пошло не так, то следует разобраться в ошибке с помощью чтения логов и действий по обстоятельствам.

Использование

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

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

Схема действий при работе с SVN

Примечание

Кружочек с вложенным кружочком на схеме означает, что действие составное — может состоять из многих различных действий.

Разберемся со всем по порядку:

1. Создание хранилища;
2. предимпортная настройка;
3. импорт проекта в хранилище;
4. создание рабочей копии;
5. редактирование рабочей копии;
6. закрепление изменений (правки);
7. выборка данных из хранилища;
8. отмена изменений.

Для того чтобы различные действия были понятны договоримся каждый из шагов снабжать популярным объяснением которое будет основано на двух персонажах:

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

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

1. Создание хранилища. Хранилище или иначе репозиторий — особое место, где SVN в собственном формате хранит все наши данные в виде правок. Директорией, где мы решили разместить хранилища, будет d:\www\svn_repository, а хранилище будет называться web-dev. Тогда создаем директорию d:\www\svn_repository\web-dev и через контекстное меню для нее выбираем TortoiseSVN→Create repository here… Тип репозитория должен быть FSFS. Хранилище создано и готово к работе;
   

   метафора

   Этот шаг можно сравнивать с примерным лидером который готовит рабочее место для разработчика наряду с созданием ftp аккаунтов и прочих подобных вещей.

2. Предимпортная настройка. Этот шаг опционален и не является каноническим, однако я бы порекомендовал делать его всегда, когда его есть к чему применить. Речь пойдет о настройке рабочей копии в плане задания свойства игнорирования файлов, для которых не нужно хранить информацию о версии (версионировать). Примером таких файлов могут быть «скомпилированные» шаблоны Smarty, файлы проекта редактора PhpED, дампы баз и прочее, что по каким-то причинам расположено в рамках рабочей копии, но не нуждается в отслеживании изменений. Создайте простую копию проекта, а в оригинале удалите все то, что не считаете нужным отдать под версионирование. Пока это все;
   

   метафора

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

3. Импорт проекта в хранилище. Здесь необходимо сообщить хранилищу базовую редакцию проекта на основе которой он будет, подобно пирамиде из правок (часто очень причудливой — подумайте о ветвлении), хранить наши изменения. Пусть это будет проект блога в котором размещена эта статья: d:\www\ApachePhpMysql\apache\home\web-dev.info\. Импорт осуществляется посредством пункта контекстного меню TortoiseSVN→Import… В качестве запрошенного URL к хранилищу укажите http://127.0.0.1/svn/web-dev/trunk.
   

   для ясности

   Частичка svn в этом пути взялась из httpd.conf, где мы указали ее в директиве Location, с тем же успехом можно было бы написать в обоих местах my_pretty_good_svn_directory. Что касается частички trunk, то по ее поводу забегите немного вперед, если вам интересно.

   В зависимости от объема импортируемых данных зрелище будет более или менее впечатляющее… и длительное;

   метафора

   Лидер создает фундамент на котором силами разработчика будет строиться вся разработка. Таковым фундаментом является первая правка в хранилище — результат прошедшего импорта.

4. Создание рабочей копии. Теперь самое время… удалить оригинал вашего проекта.
   

   Внимание!

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

   Делается это потому, что оригинал проекта не содержит еще данных о версиях файлов, а значит, не является рабочей копией. Директорию нужно таковой сделать. Для этого и производится удаление, чтобы потом создать под этим же именем директорию, которая будет рабочей копией с точки зрения SVN и файлами, составляющими блог, с точки зрения Apache. Далее, для пустой директории web-dev.info запустите команду контекстного меню SVN→Checkout…, URL хранилища нужно взять из предыдущего шага: http://127.0.0.1/svn/web-dev/trunk. Теперь, после завершения, у вас есть рабочая копия вашего хранилища, с которой можно производить любые действия, вплоть до забрасывания проекта;

   метафора

   Лидер продолжает заботиться о разработчике и делать свою работу. На этом этапе он создал собственную рабочую копию т.к. необходимо навести порядок с файлами, исключенными на этапе предимпортной настройки. Тем, что над лидером нет никого, кто сделал бы эту работу для него и обусловлена эта чехарда с удалением оригинала и созданием пустой директории.

5. Редактирование рабочей копии.
   Тут можно дать волю фантазии, например, отбросить ее в сторону и заняться делом. Под редактированием понимается любое изменение содержимого файлов, их переименование, изменение свойств и прочее. Все эти телодвижения скажутся на рабочей копии так, что нам надо будет их сохранить, а в терминах SVN — закрепить. Давайте потратим нашу первую правку на что-нибудь полезное: второй этап настройки списка игнорируемых объектов. Мысленно вернитесь к этапу предимпортной настройки. По его результатам у нас имеется оригинал, ставший после последующих шагов рабочей копией и старая резервная копия. Скопируйте резервную копию поверх рабочей копии. выполните для последней команду TortoiseSVN→Check for modifications и вы увидите все файлы, которые решили не версионировать с пометкой «non-versioned». Можно отметить их как игнорируемые, в чем клиент предоставляет нам довольно большую свободу посредством контекстного меню, вызываемом при клике правой кнопкой мыши на не версионированных объектах. Дело за вами и пусть эти изменения будут пока единственными;

   метафора

   Лидер и разработчик на данном шаге одноправны — оба вносят различного рода изменения. То, что мы лишь добавили игнорирование некоторых объектов, не говорит, что это единственное действие, которое можно производить для изменения хранилища. Например, разработчик всегда будет менять файлы, находясь на этом этапе, самом часто посещаемом.

6. Закрепление изменений. Действие сводится к выбору команды контекстного меню SVN Commit… Причем для какого объекта вы ее выбрали, тот и будет закреплен. Это открывает большие возможности по ветвлению в рамках одной ветки: можно разбить ряд внесенных изменений по правкам. Commit для всей рабочей копии, естественно приведет к закреплению всех изменений, что вы и сделали в конце предыдущего шага. Вообще, закрепление изменений рекомендуется делать осмысленно. Не раз в день, не каждые 3.14 минуты, а по задаче. В качестве примера, локализация плагина WordPress — отличная вещь, умещающаяся в одной правке. А вот локализацию большего их числа лучше разбить на несколько. Идея проверить что-либо «на живую» тоже вполне втиснется в рамки одной правки. Другое дело, если «что-либо» это что-то кардинальное, да и к тому же конфликтующее с текущими наработками, тогда дело за ветками, о чем как-нибудь потом;
7. выборка данных из хранилища. Широкие горизонты этой возможности открывает нам команды SVN Update и TortoiseSVN→Update to revision… Первая берет самую актуальную информацию об объекте для которого применена, а вторая позволяет выбрать номер правки из которой будет взята информация — машина времени в действии. Номер необходимой правки можно узнать по щелчку на кнопке Show Log. Еще к выборке можно отнести и команду SVN Checkout, которая также позволяет выбрать номер правки для выборки, но доступна эта команда только для объектов не находящихся в поле рабочей копии. Таким образом, можно всегда создать рабочую копию любой правки, что также есть путешествие во времени;
8. Отмена изменений. Действия по изменению объектов рабочей копии можно отменить. Для этого существует команда TortoiseSVN→Revert…, которая заменяет объект своим кэшированным вариантом, который соответствует последней правке. Обращения к серверу не будет, кэш находится в системных директориях .svn;

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

Подводные камни и нюансы

1. Пути. Устоявшимся стандартом организации путей в хранилище является создание трех «директорий»: trunk, tags и branches, причем текущая разработка обычно находится в trunk, а остальные используются по мере надобности. Именно поэтому пути в примерах несколько странные на первый взгляд. Зачем и почему принята такая структура можно узнать из соответствующих глав книги SVN Book;
2. удаление и прочие файловые операции. Если вы решили удалить или переименовать какой-то объект рабочей копии, то делайте это посредством соответствующих команд контекстного меню — изменение часть файловой системы и хранилища при последующем commit — разные вещи;
3. рекурсивные свойства. Если вы добавляете в рабочую копию новую директорию, а где-то для ее предков установлено свойство с пометкой «apply property recursively», то его надо переустановить, чтобы оно было выставлено и для новой директории;
4. что если ошибка? На наше счастье операции commit и update — атомарные. Это значит, что если на протяжении этих операций возникает ошибка, то операции просто не было. Это очень напоминает транзакции;
5. ошибка «… probably out of date …». В случае данного сообщения попытайтесь сделать update для объекта (чаще всего это директории), обычно это помогает. Дело в то, что объект был изменен как в рабочем копии, так и в хранилище. Объект необходимо сначала обновить: update попытается объединить локальные изменения с опубликованными. Если SVN не сможет самостоятельно совершить объединение, он предложит пользователю разрешить конфликт вручную;
6. ошибка при изменении комментария к правке: «DAV request failed; it’s possible that the repository’s pre-revprop-change hook either failed or is non-existent». Изменения свойств хранилища по умолчанию отключены. Для активации возможности изменять логи правок создайте в поддиректории hooks хранилища файл с именем pre-revprop-change.bat и следующим кодом:

   @ECHO Off
   IF "%4" == "svn:log" GOTO :SVN_LOG
   EXIT 1
   :SVN_LOG
   EXIT 0

7. переименование объектов, сводящееся к изменению регистра символов в имени. В этом случае ошибка растет из регистронезависимости имен файлов ОС Windows. Что случается при любом переименовании файла? Клиент SVN помещает в системные поддиректории .svn переименованный файл, но также сохраняет там и старый — конфликт! Существует два пути решения такой проблемы:
   • непосредственно в хранилище (рекомендуемый)
     • закрепить правку;
     • переименовать нужный_файл.файл, используя браузер хранилища, в Нужный_Файл.файл;
     • обновить рабочую копию.
   • через временный файл
     • переименовать нужный_файл.файл в нужный_файл.файл_;
     • закрепить правку;
     • переименовать нужный_файл.файл в Нужный_Файл.файл;
     • закрепить правку.
8. перемещение через переименование. В случае, когда в рабочей копии необходимо перенести объект необязательно его удалять и добавлять заново. Воспользуйтесь функцией переименования и укажите относительный путь конечной директории;
9. Игнорирование родителя. Если вы занесли в игнор-лист некую директорию, то все ее дочерние элементы будут игнорироваться автоматически, что удобно при разнородном содержимом директории.

Заключение

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