Разработка модуля для Drupal. Часть2
Ромка — Вс, 01/03/2010 - 19:31
currencies.info
В .info-файлах модулей содержится служебная информация, без которой модуль не будет виден в системе. Начинаться любой .info-файл должен со строки
- ; $Id$
В файлах с PHP-кодом после открывающего тега <?php необходимо добавить строку
<?php
// $Id$
?>Эту строку, если модуль будет размещен в официальном CVS-репозитории Drupal, заменит служебная информация. Далее в файле .info должны располагаться три обязательных параметра: название модуля, его описание и версия ядра Drupal, с которой работает модуль. Кроме того, в этом файле могут находиться необязательные параметры: минимальная версия PHP, необходимая для запуска модуля, зависимость от других модулей Drupal, без которых текущий модуль не будет работать, и пр. Подробное описание всех доступных к использованию в .info-файле параметров можно найти в официальной документации (ссылка на эту и другие цитируемые в статье страницы документации размещена во врезке «Ссылки на документацию»).
В нашем случае файл currencies.info будет иметь такой вид:
- ; $Id$
- name = Currencies block
- description = Show currencies
- core = 6.x
Административный интерфейс
Теперь приступим к реализации каждого из описанных этапов. Для начала добавим в наш файл currencies.module функцию с реализацией хука hook_perm, который, как сказано выше, определяет дополнительные права доступа. Hook_perm — один из самых простых хуков, он всего лишь возвращает массив строк, представляющих собой права доступа. После инсталляции модуля администратор сайта на странице Admin — Permissions (admin/user/permissions) может указать, какие группы пользователей имеют право доступа access currencies block settings, а мы в дальнейшем, во время реализации формы настроек модуля при помощи функции user_access, будем проверять, имеет ли текущий пользователь право доступа access currencies block settings или нет.
<?php
function currencies_perm() {
return array('access currencies block settings');
}
?>Важный момент. Пользователь с uid=1, т. е. первый созданный в системе, является суперпользователем, для него функция user_access всегда возвращает значение TRUE, а это значит, что он всегда имеет доступ ко всем функциям сайта. Это одна из причин, почему не рекомендуется работать в системе с учетной записью суперпользователя: зачастую разработчики забывают раздавать пользователям необходимые права доступа, так как сами, работая как суперпользователи, не имеют проблем с доступом к ресурсам сайта.
Для определения дополнительного системного пути, по которому в нашем примере будет доступна страница управления модулем, необходимо создать реализацию хука hook_menu:
<?php
function currencies_menu() {
$items = array();
$items['admin/settings/cur-block'] = array(
'title' => t('Currencies block settings'),
'description' => 'Currencies block settings.',
'page callback' => 'drupal_get_form',
'page arguments' => array('currencies_settings'),
'access arguments' => array('access cur block settings'),
);
return $items;
}
?>Эта функция также возвращает ассоциативный массив. Ключом каждого элемента массива должен быть путь, регистрируемый в системе (в нашем случае это admin/settings/cur-block), а значением — вложенный массив, содержащий информацию о создаваемом пункте меню. Давайте разберем каждый из параметров отдельно.
Title — заголовок меню — будет использоваться при переходе на страницу с адресом admin/settings/cur-block в строке заголовка браузера (тег
Description — описание пункта меню, которое в нашем случае будет использоваться на странице администрирования.
Page callback — функция, которая будет генерировать страницу, создаваемую по указанному пути. В простом случае значением этого параметра должна быть функция, возвращающая HTML-код, который будет показан пользователю. Однако мы по указанному адресу создаем не обычную страницу, а форму, значения которой автоматически сохраняются в БД. Поэтому для параметра page callback мы назначаем вызов системной функции drupal_get_form(), которая выведет на экран форму, созданную функцией с именем, указанным в элементе массива page arguments; в нашем случае это функция currencies_settings(). Функция currencies_settings() должна вернуть ассоциативный массив, содержащий информацию об элементах создаваемой формы. Подробнее об этом массиве будет рассказано ниже.
Access arguments — массив «прав доступа». Пользователи, обладающие правами доступа, перечисленными в этом массиве, могут получить доступ к создаваемому пункту меню. Более подробную информацию о параметрах пунктов меню можно найти в документации.
Сейчас в нашем модуле определен новый пункт меню, но не определена функция, формирующая содержимое страницы, на которую этот пункт указывает (см. листинг 2).
Листинг 2
<?php
function currencies_settings() {
$form['currencies_list'] = array(
'#type' => 'textfield',
'#title' => t('Currencies'),
'#default_value' => variable_get('currencies_list',
"USD,EUR,CNY,BYR,KZT,TRY,UAH,JPY"),
'#maxlength' => 255,
);
$form['currencies_list_freq'] = array(
'#type' => 'textfield',
'#title' => t('Frequency of updating of the data
(in seconds)'),
'#default_value' => variable_get('currencies_list_freq',
3600),
'#maxlength' => 255,
'#description' => t('It is recommended to use value
not less than 3600.'),
);
$form['currencies_list_url'] = array(
'#type' => 'textfield',
'#title' => t('Адрес xml-файла'),
'#default_value' => variable_get('currencies_list_url',
"http://www.cbr.ru/scripts/XML_daily.asp?date_req=
%d/%m/%y"),
'#maxlength' => 255,
'#description' => t('The XML-file address.'),
);
return system_settings_form($form);
}
?>Как и хуки hook_menu, hook_schema и многие другие хуки Drupal, эта функция должна возвращать ассоциативный массив, на этот раз содержащий информацию о параметрах создаваемой формы. Здесь мы создаем три однострочных текстовых поля (параметр #type имеет значение textfield), значения по умолчанию для которых (параметр #default_value) будут храниться и выбираться из стандартной таблицы variables Drupal при помощи функций variable_set() и variable_get(). Благодаря использованию функций drupal_get_form и system_settings_form нет необходимости заботиться о создании кнопок Submit и Reset, а также о функциях, обрабатывающих и сохраняющих данные формы. В более сложных случаях, которые будут рассмотрены в следующей статье, придется вручную создавать функции проверки введенных пользователем значений и сохранения данных. Подробное описание типов полей, используемых в формах, можно найти в документации.
Все, мы завершили разработку первой из трех частей нашего модуля — административного интерфейса и переходим к разработке второй его части — инструмента получения данных от удаленного сервера.
Ссылки на другие части этой статьи:
- Часть 1. Основы модульной системы Друпала
- Часть 2. Разработка простейшего модуля
- Часть 3. Введение в темизацию Друпала (для программистов, а не дизайнеров)
Содержание всех статей: http://romka.eu/blog/my-drupal-articles
Всем привет!
Отправить комментарий