Moodle

13.3. Вернемся к нашему примеру сценария

Следующая часть сценария иллюстрирует некоторые дополнительные функции:

Строка 5: Получение данных запроса

$name = optional_param('name', '', PARAM_TEXT);               // 5

Действием, которое должно выполнять любое веб-приложение, является получение данных запроса (переменных, передаваемых с помощью методов запросов GET или POST) с необходимыми преобразованиями для устранения уязвимости приложения к атакам на основе SQL-инъекций или межсайтового скриптинга. Приложение Moodle предоставляет два метода выполнения этого действия.

Простой метод показан выше. При его использовании извлекается значение отдельной переменной на основании имени параметра (в данном случае name), значения по умолчанию и ожидаемого типа данных. Ожидаемый тип данных используется для удаления из входящих данных всех не соответствующих ему символов. Существует множество типов, таких, как PARAM_INT, PARAM_ALPHANUM, PARAM_EMAIL и.т.д.

Существует также функция, аналогичная функции required_param, которая также, как и все функции семейства require_... прекращает выполнение сценария и выводит сообщение об ошибке в том случае, если ожидаемый параметр не обнаружен.

Другим механизмом, поддерживаемым приложением Moodle и предназначенным для получения данных запроса является использование полнофункциональной библиотеки для работы с формами. Этот способ реализуется благодаря коду совместимости с библиотекой HTML QuickForm из PEAR. (Для разработчиков, не имеющих опыта работы с языком PHP, следует отметить, что PEAR является эквивалентом хранилища CPAN для языка PHP.) Эта библиотека казалась хорошим выбором во время поиска подходящего решения, но ее поддержка на сегодняшний день не осуществляется. В какой-то момент в будущем нам придется перейти к использованию новой библиотеки для работы с формами, чего ожидают многие из нас, так как библиотека QuickForm имеет несколько раздражающий архитектурных недостатков. На сегодняшний день, однако, она соответствует предъявляемым требованиям. Формы могут быть описаны как коллекция полей различных типов (т.е. текстовых полей, выпадающих списков для выбора элементов, полей для выбора дат) с проверкой данных на стороне клиента и сервера (включая использование описанных типов, использующих префикс PARAM_...).

Строка 6: Глобальные переменные

if (!$name) {
    $name = fullname($USER);                                  // 6
}

а также некоторые другие переменные, с некоторыми из которых мы будем иметь дело ниже.

Вы могли прочитать слова "глобальная переменная" с ужасом. Однако, следует заметить, что язык PHP обрабатывает единственный запрос в каждый момент времени. Следовательно, эти переменные не настолько глобальны. Фактически глобальные переменные языка PHP могут рассматриваться как реализация шаблона проектирования реестра уровня потока (обратитесь к книге Martin Fowler Patterns of Enterprise Application Architecture) и это тот метод, в соответствии с которым приложение Moodle использует эти переменные. Очень удобной чертой этого подхода является тот факт, что он делает доступными часто используемые объекты в коде без необходимости передачи их каждой функции и методу. Использованием этого подхода крайне редко злоупотребляют.

Все не так просто

Эта строка также позволяет описать проблемную область кода: не все так просто. Для вывода имени пользователя нужно применить более сложный подход, чем простое объединение строк $USER->firstname, '~' и $USER->lastname. В школе может действовать распоряжение о выводе любой из этих частей, а также различные культуры используют различные соглашения о том, в каком порядке выводить составные части имени пользователя. Следовательно, существует ряд переменных конфигурации и функция для объединения частей имени в соответствии с этими правилами.

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

Строка 7: Журналирование

add_to_log(SITEID, 'local_greet', 'begreeted',
        'local/greet/index.php?name=' . urlencode($name));    // 7

Все важные операции в рамках приложения Moodle подлежат журналированию. Журналы событий сохраняются в таблице базы данных. Это компромисс. Этот подход позволяет производить подробный анализ журнала достаточно просто, к тому же различные отчеты, сформированные на основе журналов событий, включены в комплект поставки приложения Moodle. Однако на сайте большого размера с большим количеством посетителей этот подход приводит к проблемам с производительностью. Таблица журнала событий увеличивается в размере, затрудняет резервное копирование базы данных и замедляет выполнение запросов данных. Также при записи данные в таблице могут объединяться. Эти проблемы могут быть преодолены различными путями, например, с помощью объединения операций записи или путем архивирования или удаления устаревших записей для перемещения их из основной базы данных.

Далее: Генерация результирующего документа