Когда модуль выполняется, он загружает исходный PHP-файл, именуемый таким же образом, как и папка, в которой он находится. В данном случае это файл modules/mod_users_latest/mod_users_latest .php.

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

В следующей строке кода вызывается метод getUsers () из вспомогательного класса для сохранения результата в переменной $ linknames. Обратите внимание на то, что этому методу в качестве аргумента передается переменная $params. В данном файле эта переменная нигде не объявляется. Откуда же она берется? Для того чтобы ответить на этот вопрос, нам придется рассмотреть, как и где выполняется рассматриваемый здесь файл. Как пояснялось в главе 3, модули выполняются по очереди, исходя из назначенного для них места в шаблоне. В конечном итоге данный процесс приводит к следующему фрагменту кода из метода renderModule () класса JModuleHelper, объявляемого в файле libraries/joomla/application/module/helper.php.

В выделенной полужирным строке кода переменная $path содержит полное имя входного файла модуля. В данном случае требуется файл mod_users_latest.php. Команда require языка РНР немедленно вводит требуемый файл в текущую программу на РНР. В конечном счете это похоже на копирование и вставку требуемого файла в данном месте текущей программы.

Следует заметить, что файл mod_users_latest.php содержит обычный сценарий РНР, но не объявление класса. Поэтому строки кода из этого файла выполняются, как только он включается с помощью команды require. Любые переменные, оказавшиеся в области действия при выполнении команды require, остаются по-прежнему в области действия и при выполнении требуемого сценария. Это означает, что в сценарии из файла mod_users_latest .php одни и те же переменные находятся в той области действия, которая имелась в методе renderModule () класса JModuleHelper, где выполнялась команда require.

Как следует из приведенного ниже фрагмента кода, переменная $params устанавливается в методе renderModule () раньше.

// получить параметры метода $params  = new  JRegistry; $params->loadJSON($module->params);

Именно отсюда она и берется. Эта переменная содержит ссылку на объект типа JRegistry, в котором хранятся дополнительные параметры, введенные при создании модуля в компоненте Module Manager. Они оказываются доступными при вызове вспомогательного метода данного модуля.

В следующей строке кода из листинга 6.1 параметр linknames выбирается среди дополнительных параметров модуля и сохраняется в переменной $ linknames. Эта переменная будет использоваться при выполнении компоновки данного модуля.

Далее следует строка кода, в которой суффикс класса данного модуля получается из объекта, доступного из переменной $params. Суффикс класса модуля представляет собой поле, в котором разработчик веб-сайта может ввести текст при создании модуля. Этот суффикс позволяет точно настроить оформление модуля с помощью вложенных таблиц стилей присваиванием особого класса CSS соответствующим элементам разметки модуля в коде HTML. Для дополнительной обработки получаемого значения вызывается встроенная в РНР функция html special chars (), преобразующая символы, имеющие особое значение в коде HTML, например, угловые скобки (< и >), одинарные и двойные кавычки, амперсанд (&), в специальные знаки HTML (\, >, " и &агар;). Этим гарантируется, что неумышленный или злоумышленный код HTML не попадет в результат, выводимый из данного модуля.

И в последней строке рассматриваемого здесь кода выполняется команда require, как показано ниже.

require JModuleHelper::getLayoutPath('mod_users_latest', $params->get ('layout',  'default') ) ;

В этой строке кода выполняется несколько действий. Прежде всего в ней выбирается дополнительный параметр компоновки среди параметров данного модуля. Как пояснялось в главе 4, для модулей можно создать альтернативные компоновки и выбрать их в компоненте Module Manager при создании нового экземпляра модуля. Затем в этой строке кода вызывается метод getLayoutPath () из класса JModuleHelper с указанием имени модуля и компоновки в качестве аргументов. Этот метод возвращает полное имя файла с требуемой компоновкой. Если альтернативная компоновка не указана, выбирается компоновка, используемая по умолчанию из файла modules/mod_users_latest/tmpl/default.php. И файл компоновки содержит обычный сценарий РНР, но не объявление класса, поэтому он выполняется сразу же после его включения с помощью команды require. Благодаря этому все переменные, оказавшиеся в области действия на данном этапе выполнения программы, остаются по-прежнему в области действия и при выполнении сценария компоновки.

Рассмотрим подробнее данное проектное решение. Файл mod_users_lastest.php стал доступным благодаря выполнению команды require в классе JModuleHelper. А теперь по этой же команде выбирается файл компоновки. На первый взгляд такое проектное решение кажется немного запутанным, тем не менее оно позволяет работать с более компактными файлами программ, храня отдельные части программы в разных папках. Эти преимущества перевешивают недостатки, связанные с необходимостью отслеживать места включения одних файлов в другие.

Подведем итог всем функциям кода из файла mod_users_lastest.php.

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

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