2.3. Техническая реализация программного продукта, алгоритмы и коды

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

При создании класса работы с таблицей производим добавление методов для взаимодействия с данными из таблицы.

Работа с таблицей хранящей ответы осуществлялась через класс Models_DbTable_Answes, его код отображен на рисунке 3. Этот класс является наследником класса Zend Framework для работы с таблицами. При создании необходимо указать в переменной «_name» имя таблицы с которой производиться работа. Далее следует функция «insertData», которая позволяет добавлять в таблицу данные из массива.

Рисунок 3 – Создание и описание класса Models_DbTable_Answes.

Работа с таблицей хранящей вопросы осуществлялась через класс Models_DbTable_Questions, его код отображен на рисунке 4. Этот класс является наследником класса Zend Framework для работы с таблицами. Также имеет функцию «insertData», которая позволяет добавлять в таблицу данные из массива.

Рисунок 4 - Создание и описание класса Models_DbTable_Questions.

Работа с таблицей хранящей описание тестов осуществлялась через класс Models_DbTable_ Tests, его код отображен на рисунке 5. Этот класс является наследником класса Zend Framework для работы с таблицами. Также имеет функцию «insertData», которая позволяет добавлять в таблицу данные в виде массива в таблицу отвечающую за информацию о тесте.

Рисунок 5 - Создание и описание класса Models_DbTable_Tests.

Для сохранения и импорта информации был выбран формат DOCX. Это удобный формат для хранения различного рода текстовой информации.

Office Open XML (OOXML, DOCX[, проект ISO/IEC IS 29500:2008) — серия форматов файлов для хранения электронных документов пакетов офисных приложений — в частности, Microsoft Office. Формат представляет собой zip-архив, содержащий текст в виде XML, графику и другие данные, которые могут быть переведены в последовательность битов (сериализованы) с применением защищённых патентами двоичных форматов, спецификации которых были опубликованы Microsoft для пользователей OOXML на условиях Microsoft Open Specification Promise.

Первоначально формат создавался как замена прежнему двоичному формату документов, который использовали приложения Microsoft Office вплоть до версии Office 2003 включительно. В 2006 году формат Office Open XML был объявлен свободным и открытым форматом Ecma International. Он является форматом по умолчанию для приложений Microsoft Office 2007 и более поздних.[3]

Осуществление импорта информации из файла осуществляется через специально разработанный для работы с файлами типа «docx» класс Models_Import. Листинг приведен в приложении Б. Он позволяет считывать данные из файлов MS Word и превращать текст из них в символьную строку. Так как «docx» по своей сути являются zip архивами с XML шаблонами, поэтому работа ведется с использованием класса ZipArchive. Структура файла docx отображена на рисунке 6.

Рисунок 6 – структура файла DOCX.

Класс ZipArchive позволяет производить различные манипуляции с архивами формата zip. Находящиеся в нем XML файлы анализируются и преобразовыаются. Необходимые XML файлы расположены в директории word и их структуру можно посмотреть на рисунке 7. Как мы видим в этой директории присутствуют различные файлы, каждый из них хранит свой список сведений о тексте в документе и собственно сам текст.

Рисунок 7 – структура директории с необходимыми для обработки файлами.

Для осуществления импорта файла генерируется форма приёма файлов с использованием Zend_Form, ниже на рисунке 8 представлена часть кода генерации.

Рисунок 8 – генерация формы импорта.

При принятии файла необходимо установить атрибуты пересылки информации через метод setAttrib. После чего создается новый объект класса Zend_Form_Element_File с именем «data». Установка дополнительных параметров позволяет добавить пояснительную надпись и установить фильтрацию типа файла, для безопасности. Итоговый html код формы представлен в приложении Д.

Процедура импорта выполнена в виде обработки получившейся строки текста из файла и разбиению его на массив строк, отображено на рисунке 9. Данный массив имеет специализированную структуру для последующего импорта информации в базу данных тестирования. Примерная структура массива: $array = (

array(

'settings' => array(

'uid'=>Индентификатор,

'name'=>Название теста

),

'questions' => array(

array(Вопрос),

array(Варианты ответов)

Рисунок 9 – разбиение на массив.

Работа модуля обеспечивается через контроллер manage через action- import. Исходный код модуля отображен в приложении В.

Модуль создания отчета по тесту, для сохранения его во внешнем файле формата docx, состоит из функции «reportAction» и шаблона для отображения с использованием html, исходный код шаблона отображен в приложении Г. Дополнительно в модуле присутствует система поиска и фильтрации результата, для упрощения работы с множеством тестов.

Когда получена информация через GET запрос о том какой тест вывести в виде отчета, производится вызов класса Models_Word для создания нового файла «DOCX». После успешного создания файла, пользователю предоставляется возможность скачать его для дальнейшей работы с ним.

Шаблон по мимо статических Html данных хранит в себе участки для динамической подстановки значений написанные на PHP. При выборе пункта создания отчета генерируется меню отчета. Листинг кода отображен на рисунке 10.

Рисунок 10 – листинг кода генерации меню выбора.

После вызова «foreach» происходит добавление в цикле на страницу всех доступных тестов и генерация для них действий по шаблону.

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

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

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

В отличие от метода GET, метод POST не считается идемпотентным, то есть многократное повторение одних и тех же запросов POST может возвращать разные результаты (например, после каждой отправки комментария будет появляться одна копия этого комментария).

При результатах выполнения 200 (Ok) и 204 (No Content) в тело ответа следует включить сообщение об итоге выполнения запроса. Если был создан ресурс, то серверу следует вернуть ответ 201 (Created) с указанием URI нового ресурса в заголовке Location. Сообщение ответа сервера на выполнение метода POST не кэшируется.

Запросы обрабатывается в функции reportAction, с листингом которой можно ознакомиться в приложении Д. При получении сведений о выборе теста генерируется новый файл с информацией о тесте, цикл записи строк отображен на рисунке 11. Данные записываются через цикл с предусловием пока не закончатся «вопросы» в тесте.

Рисунок 11 – цикл с предусловием.

Для отправки данного файла пользователю необходимо сначала отключить вывод на странице, это действие не допускает попадания в итоговый файл мусорной информации, содержащийся на странице. Отправка осуществляется через стандартную процедуру, которая отображена на рисунке 12. Как видно отправка осуществляется через установку значений заголовков HTTP. Заголовки HTTP (англ. HTTP Headers) — это строки в HTTP-сообщении, содержащие разделённую двоеточием пару имя-значение. Формат заголовков соответствует общему формату заголовков текстовых сетевых сообщений ARPA. Заголовки должны отделяться от тела сообщения хотя бы одной пустой строкой. Общий формат «название» : «значение». Название параметра должно состоять минимум из одного печатного символа (ASCII-коды от 33 до 126). Регистр символов в названиях не имеет значения. Заголовки с неизвестными именами должны игнорироваться. После названия сразу должен следовать символ двоеточия.[6]

Значение может содержать любые символы ASCII кроме перевода строки (код 10) и возврата каретки (код 13). Пробельные символы в начале и конце значения обрезаются. Последовательность нескольких пробельных символов внутри значения может восприниматься как один пробел. Регистр символов также не имеет значения (если иное не предусмотрено форматом поля).

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

Заголовки с одинаковыми названиями параметров, но разными значениями могут объединяться в один только если значение поля представляет из себя разделённый запятыми список. Во всех остальных случаях значения более дальних заголовков должны перекрывать предыдущие. Поэтому прокси-сервера не должны менять порядок следования заголовков в сообщении. При этом порядок элементов списка обычно значения не имеет.

Рисунок 12 – отправка файла пользователю.