Разработка информационного web-сайта на основе системы «1С-Битрикс: Управление сайтом»

//вызов функции

var paths = ajax_state_string(“http://www.metagames.ru/index.php?filter=up&datei=10”, new Array());

/*

далее идет ajax-запрос с использованием технологии AJAX к странице с адресом paths[0]

*/

//сохраняем строку состояния в адресной строке браузера

window.location += “#”+paths[1];

Следующим шагом является написание функции для восстановления из адресной строки браузера состояния загруженной страницы:

function restore_hash_part(path, result_block, ar_next, ajax_status_id, filterupped){}

Функция принимает следующие параметры:

• path – путь, указанный в адресной строке браузера;
• result_block – ID элемента страницы, в который должен быть загружен результат;
• ar_next – массив, содержит в качестве первого элемента (индекс - 0) имя переменной, в качестве второго элемента (индекс 1) значение переменной, указывающей на то, что имеет смысл восстанавливать состояние (это не простой, а ajax-запрос);
• ajax_status_id – ID элемента страницы для визуальной анимации процесса восстановления состояния;
• filterupped – логическая переменная. Если true, процесс восстановления выполнен не будет;

Эта функция может быть вызвана сразу после загрузки страницы. Типичный пример использования:

//момент загрузки страницы

window.onLoad = function()

{

restore_hash_part(window.location, “result_block_id”, new  Array(“filter”, “up”), “ajax_status_id”, false));

}

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

6.5.3. Обработка событий панели управления.

В предыдущей главе при создании структуры web-приложения не было учтено требование «оценка игры должна считаться на основе оценок, указанных в обзорах к игре». Данное требование могло бы быть реализовано в логике работы компонентов, выводящих информацию по играм. Но каждый раз подсчитывать оценку, постоянно обращаясь к элементам информационного блока «Обзоры», слишком ресурсоёмко с точки зрения использования ресурсов компьютера и скорости работы страниц web-приложения. Например, один из списков игр содержит 40 записей, каждая из которых соотносится в среднем с пятью обзорами. Итого – нужно просмотреть в среднем 200 обзоров, что может заметно увеличить скорость загрузки страницы. Наиболее приемлемым средством реализации требования была бы возможность автоматического расчёта и установки значения оценки игры при создании, изменении или удалении обзора, т.е., выражаясь в терминах системы, установки значения свойства с кодом MAIN_METAMARK элемента информационного блока «Игры» при изменении, удалении или добавлении элемента информационного блока «Обзоры», в котором в значение свойства с кодом GAME_ID совпадает с идентификатором элемента информационного блока «Игры». Но вносить изменения в сценарии работы панели управления системы не рекомендуется. Таким образом, актуальным становится вопрос, как можно перехватить событие добавления элемента информационного блока.

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

• Событие добавления элемента информационного блока. Нас интересует событие, наступающее при успешном добавлении элемента. В системе данное событие имеет код «OnAfterIblockElementAdd»;
• Событие изменения элемента информационного блока. Код – «OnAfterIblockElementUpdate»;
• Событие удаления элемента информационного блока. Код – «OnBeforeIblockElementDelete»;

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

• Получить данные элемента информационного блока, участвующего в событии;
• Определить информационный блок, которому принадлежит элемент;
• Если информационный блок не соответствует информационному блоку «Обзоры», прекратить обработку события;
• Определить изменяемый элемент информационного блока «Игры» (свойство с кодом GAME_ID);
• Провести расчёт и присвоить полученный результат свойству с кодом MAIN_METAMARK элемента информационного блока «Игры».

Чтобы зарегистрировать обработчик, необходимо воспользоваться встроенной функцией API системы:

void AddEventHandler(string from_module_id, string event_id, mixed callback, int sort = 100, mixed full_path = false)

from_module_id – идентификатор модуля, который будет инициировать событие;

event_id – идентификатор события;

callback – название функции обработчика;

sort – очередность (порядок), в котором выполняется данный обработчик;

full_path – полный путь к файлу для подключения при возникновении события перед вызовом callback;

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

AddEventHandler("iblock", "OnAfterIblockElementAdd", "add_review_handler");

AddEventHandler("iblock", "OnAfterIblockElementUpdate", "add_review_handler");

AddEventHandler("iblock", "OnBeforeIblockElementDelete", "delete_review_handler");

Для реализации алгоритма, указанного выше, написано две функции:

void delete_review_handler(int ID)

Функция – обработчик события удаления элемента информационного блока с идентификатором ID.

void add_review_handler(array &arFields)

Функция – обработчик события добавления элемента информационного блока. $arFields – передаваемый по ссылке массив с данными добавленного элемента. Эта же функция обрабатывает и событие изменения элемента.

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

 

7. Резервное копирование данных web-приложения. Система управления версиями

7.1. Общие сведения

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

Помимо данных, хранящихся в БД, опасности некорректного изменения подвержены и файлы, хранящиеся в файловой системе компьютера web-приложения и обеспечивающие его работу. В первую очередь, существует опасность взлома и изменения файлов, содержащих сценарии на языках PHP, JavaScript, которые обеспечивают работу системы и web-приложения. Помимо несанкционированного доступа существует опасность изменения файлов сценариев и посредством санкционированного доступа, например, изменения текстов сценариев разработчиками, занимающимися поддержкой и обслуживанием web-приложения, которые могут быть некорректными и дестабилизировать работу web-приложения. Поэтому необходимо обезопасить данные и файлы web-приложения, обеспечив их резервное копирование.

7.2. Реализация резервного копирования

Для того чтобы защитить данные, хранящиеся в базе, следует воспользоваться утилитами, предоставляемыми СУБД. В нашем случае это утилита mysqldump [5], предоставляемая СУБД MySQL. Эта утилита должна быть запущена из командной строки операционной системы, которая отвечает за работу web-приложения. В нашем случае это операционная система GNU/Linux, т.е. для запуска утилиты можно воспользоваться командной оболочкой Bourne Shell [3]. В процессе реализации резервного копирования был написан сценарий на языке Bourne Shell, который обеспечивает резервное копирование данных и сохраняет файл копии  в файловой структуре web-приложения.

DUMP_FILE_NAME=`date +%Y%m%d%H%M%S`

mysqldump –u[логин_пользователя] –p[пароль] -f [имя_базы_данных] > /tmp/$DUMP_FILE_NAME.sql

if [ $? -eq 0 ]

  then

    gzip -c /tmp/$DUMP_FILE_NAME.sql  > /home/bitrix/www/bitrix/backup/$DUMP_FILE_NAME.auto.sql.gz

    chmod 644 /home/bitrix/www/bitrix/backup/$DUMP_FILE_NAME.auto.sql.gz

    chown bitrix:bitrix /home/bitrix/www/bitrix/backup/$DUMP_FILE_NAME.auto.sql.gz

fi

rm -f /tmp/$DUMP_FILE_NAME.sql

В данном сценарии происходит вызов утилиты mysqldump с указанием имени БД, логина и пароля пользователя для доступа к БД. Далее происходит сохранение файла в локальной директории компьютера с последующим его сжатием с помощью утилиты gzip и назначения прав доступа и имени пользователя ОС для доступа к этим файлам на скачивание посредством панели управления системы «1С – Битрикс: Управление сайтом». Локальная копия файла в конце удаляется. Теперь, присвоив данному сценарию имя mysql_dump.sh, можно осуществить резервное копирование данных посредством вызова данного сценария:

[root@v8733 sh_scripts]# ./mysql_dump.sh

Для организации резервного копирования файловой структуры web-приложения был написан сценарий file_dump.sh.

DUMP_FILE_NAME=`date +%Y%m%d%H%M%S`

tar --exclude=bitrix/backup -czf /home/bitrix/www/bitrix/backup/$DUMP_FILE_NAME.auto.file.tar.gz /home/bitrix/www

if [ $? -eq 0 ]

then

  chown bitrix:bitrix /home/bitrix/www/bitrix/backup/$DUMP_FILE_NAME.auto.file.tar.gz

fi

В данном сценарии происходит архивация данных с помощью утилиты tar с последующим сохранением архива в файловой структуре web-приложения. Из архива логично исключается сам раздел, который будет хранить резервные копии файлов и архивов. Аналогично процесс резервного копирования можно выполнить, запустив на выполнение данный сценарий:

[root@v8733 sh_scripts]# ./file_dump.sh

Данные сценарии решают задачу резервного копирования данных, хранящихся в базе данных и в файловой структуре web-приложения, но для полной автоматизации данного процесса необходимо сделать так, чтобы данные копировались автоматически, т.е. в определенное время с определенной периодичностью. Для того чтобы реализовать данное требование, необходимо воспользоваться демоном – планировщиком задач cron. Для того чтобы поставить данному планировщику задание, необходимо создать в файловой структуре компьютера web-приложения файл задач. В нашем случае данный файл будет иметь имя «cron.tasks». Для того, чтобы поставить задачу осуществления резервного копирования данных и файлов web-приложения на определенное время, необходимо внести в файл cron.tasks следующий текст:

01 3 * * * /home/bitrix/sh_scripts/mysql_dump.sh 1>/dev/null 2>/home/bitrix/logs/mysql_dump.log

10 3 * * 2 /home/bitrix/sh_scripts/file_dump.sh 1>/dev/null 2>/home/bitrix/logs/file_dump.log

В данном тексте указываются строки, каждая из которых содержит задачу с указанием времени, имени сценария, который должен быть запущен в указанное время. Таким образом, сценарий mysql_dump.sh, отвечающий за запуск резервного копирования данных БД, будет запущен в 3:01:00 каждый день, сценарий копирования файловой системы будет запущен в 3:10:00 каждый второй день недели, т.е. каждый вторник. Такой принцип распределения времени выбран потому, что данные БД меняются достаточно часто, в то же время объем, занимаемый файлом резервной копии, достаточно долго не будет превышать размер более 10 Мб. Поэтому эти данные можно резервировать каждый день. А файловая система изменяется достаточно редко, в то же время файл резервной копии (т.е. архив) занимает на диске компьютера web-приложения более чем 30 Мб. Поэтому файлы следует копировать раз в неделю. Также важно «развести» процесс копирования данных файловой системы и БД, чтобы исключить излишнюю нагрузку на компьютер web-приложения. Опытным путем выяснено, что копирование данных БД проходит менее чем за 2 минуты, процесс, отвечающий за копирование данных файловой системы, наоборот, выполняется более чем за 2 минуты, поэтому процесс копирования файловой системы решено запускать через 10 минут после запуска процесса резервного копирования БД.

Теперь, чтобы окончательно зафиксировать задачи планировщика, следует запустить утилиту crontab:

[root@v8733 sh_scripts]# crontab cron.tasks

После её выполнения которой задачи будут зафиксированы.

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

7.3. Система управления версиями

7.3.1. Описание системы Subversion

Система управления версиями используется в процессе разработки и обслуживания web-приложений. Основной задачей системы управления версиями является обеспечение совместного редактирования и использования информации. Использование данной системы обеспечивает возможность командной разработки web-приложения и централизованного хранения данных в едином хранилище. Хранилище может быть расположено на удаленном сервере и к нему должна быть обеспечена возможность удаленного доступа нескольких клиентов. Система управления версиями решает одну из важнейших проблем совместной разработки и изменения информации – проблему разделения файлов.

Для обеспечения возможности командной разработки мной была использована централизованная система управления версиями Subversion. На данный момент Subversion, которую еще называют SVN по имени входящей в дистрибутив системы клиентской программы, является ведущей системой управления версиями, данную систему используют ведущие компании по разработке web-приложений. В системе Subversion реализована модель «Копирование – Изменение – Слияние» [4], позволяющая разработчикам независимо друг от друга разрабатывать сценарии web-приложения, объединяя результаты своих трудов в едином централизованном хранилище, чаще всего расположенном на компьютере, на котором находится web-приложение.

Хранилище содержит информацию в форме дерева файлов — типичном представлении файлов и каталогов. Любое количество клиентов подключается к хранилищу и читает или записывает эти файлы. Записывая данные, клиент делает информацию доступной для остальных. Читая данные, клиент получает информацию от других. Хранилище в системе Subversion принято называть репозиторием. Данные действия отражены на рисунке 8.

Рисунок 8 – схема работы системы управления версиями

С точки зрения пользователя хранилище Subversion представляет собой «двумерную» файловую систему. Объекты в хранилище (файлы и директории) идентифицируются двумя «координатами»: именем и номером ревизии. Другими словами, хранилище представляет собой массив мгновенных снимков (ревизий) дерева файлов и директорий, индексируемый номером ревизии. Каждый такой снимок  - обычная (одномерная) файловая система. Каждый клиент (в нашем случае – разработчик web-приложения) может сделать такой снимок (checkout) и  записать его на диск своего локального компьютера. Такой снимок называется рабочей копией. Рабочая копия — это созданная клиентской программой Subversion локальная копия части данных из хранилища, содержащая помимо собственно данных некоторую служебную информацию (скрытые директории с именем .svn). Далее клиент может осуществлять изменения файлов рабочей копии на своем локальном компьютере. После изменения файлов клиентом он может зафиксировать (commit) данные изменения в самом репозитории. Еще одним важным действием, которое может выполнить клиент, является слияние (update) последних изменений файлов репозитория с рабочей копией. Данное действие позволяет обеспечить наличие у клиента самой последней версии файлов репозитория. Можно также обновить рабочую копию до определенной версии, указав её номер. Перед непосредственным использованием системы управления версий в web-приложении следует упомянуть еще одно действие – откат (revert) изменений. Данное действие позволяет отменить изменения, сделанные в рабочей копии клиента и вернуть файл в состояние, которым он обладает в репозитории.