Просмотр исходного текста страницы Создание встроенного модуля CMS. Часть 3

Статья подразумевает, что вы уже прочитали [[Создание встроенного модуля CMS|первую часть]].

Рассматривается вопрос разделения модуля на часть для посетителей и часть для администратора сайта.

Статья пишется по горячим следам разработки модуля гостевой книги. Поэтому сразу сделаем допущение, что внутреннее имя у него '''guestbook'''.

== Самый простой вариант ==

Вывод разных строк в зависимости от того, сайт это или админка.

<source lang="perl">
sub guestbook()
{
	if ( defined param('edt') )
	{
		print "Hello, admin interface!";
	}
	else
	{
		return "Hello, site!";
	}
}
</source>

Обратите внимание, для сайта всё ещё действует правило, обязывающее возвращать данные (return). А в админке следует использовать print. Разумеется, это никак не мешает накапливать данные в переменных и под конец выдать их в нужном порядке.

== Собственная таблица для произвольных данных ==

Сделаем таблицу:

<source lang="sql">
CREATE TABLE GUESTBOOK (
    ID         INTEGER NOT NULL,
    NAME       VARCHAR(128),
    TEXT       BLOB SUB_TYPE 1 SEGMENT SIZE 80,
    POST_DATE  TIMESTAMP,
    published  SMALLINT DEFAULT 0,
    OWNER      INTEGER NOT NULL
);
</source>

Пройдёмся по полям:
* '''ID''' — идентификатор объекта, Это общая рекомендация проектирования баз данных, рекомендуем всегда создавать его для любых, это намного упростит вам дальнейшую разработку.
* '''NAME, TEXT, POST_DATE''' — это уже произвольные поля, которые могут быть какими угодно для потребностей вашего нового модуля. Для простейшего примера гостевой книги их будет достаточно.
* '''published''' — признак опубликованности. Для модуля новостей это может быть признаком черновика; для навигации это может быть галочкой, включающей пункт в меню; для гостевой книги это будет признак одобрения модератором. 0 будет означать "сообщение на рассмотрении", 1 — "одобрено к показу на сайте".
* '''OWNER''' — владелец сайта. '''6''' у нас всегда школльный сайт, остальное — блоги. Об этом важно помнить при разработке всех модулей, которые будут писать и читать из базы. Вам не нужно каждый раз выяснять владельца, [[CMS]] уже заботится об этом. Когда выполняется модуль, глобальная переменная <code>$owner</code> уже содержит какое-то число, равное идентификатору авторизованного пользователя в админке либо автора сайта. Вам остаётся только использовать его для вставки в базу данных для этого владельца или выбирать из базы данные только для такого владельца. Таким образом реализуется хранение данных для сайта и блогов в одной таблице. Ниже будет приведён пример использования владельца. $owner всегда определён, потому что выполнение модуля в режиме админки без авторизации невозможно, выполнение модуля на сайте без определения владельца тоже невозможно (будет выдана ошибка 404, ни один модуль не выполнится).

=== Добавление данных ===

Форма ввода сообщения в самом простом случае выглядит так:

<source lang="html4strict">
<form class="guestbook" method="post">
	Имя:   <input type="text" name="name">
	Текст: <textarea name="text"></textarea>
	<button type="submit">Отправить</button>
</form>
</source>

Пример реакции на отправку этой формы:

<source lang="perl">
my $name = param('name');
my $text = param('text');
sqlb("INSERT INTO GUESTBOOK
	(NAME, TEXT, POST_DATE, published, owner)
	VALUES
	(?,    ?,    NOW()),    0,         $owner",
	$name, $text
);
</source>

=== Отступление о безопасности ===

Забрать данные из запроса пользователя с помощью функции param() и сразу использовать их небезопасно. В этом цикле статей используется простейший код, не содержащий проверок на корректность данных. Для ознакомления с методами защиты данных настоятельно рекомендуется прочитать статью [http://dj-andrey.ru/articles/perl-web-application-security Защита веб-приложений на Perl].

В портале уже есть встроенные методы проверки данных. Например, прочитайте функции sec_* в common.pl.

Использовать их просто:

<source lang="perl">
# обязательная проверка
my $id  = param('id');
sec_gt0($id);

# проверка параметра, которого может и не быть
my $opt = param('opt');
sec_gt0($opt) if defined($opt);
</source>

В common.pl с версии 5.2 доступна функция, упрощающая безопаное чтение данных для записи в базу и последующего показа на сайте:

<source lang="perl">
# пример использования
my $a = param_dexss_lim('a', 64);
</source>

Смысл: прочитать параметр по имени a, отразить XSS, взять не более 64 символа.

=== Чтение данных ===

<source lang="perl">
my $query = sqlp("select * from guestbook where published = 1 and owner = $owner");
# sqlp выполняет DBI::prepare, затем DBI::execute
# $query — это результат функции DBI::prepare
</source>

Обратите внимание на условие выборки. В выдачу попадут только опубликованные материалы и только принадлежащие владельцу сайта.

== Отладка ==

Наши удобные обёртки (а именно функции sql* в common.pl) скрывают от нас DBI с его громоздкими конструкицями, предназначенными обработки ошибок.

Стоит вам допустить ошибку в запросе, как функция sql* выбросит сообщение, понятное постороннему человеку.

[[Файл:sql_error.png]]

Но нам-то это не помогает понять, что произошло, а главное где. У портала есть режим отладки, который сильно помогает при разработке, который очень рекомендуем включить у себя для удобства отладки, но крайне не рекомендуем включать на боевом сервере, поскольку раскрывается множество технических подробностей, которые: во-первых, никак не помогут посетителям, если что-то случилось; во-вторых, выдадую лишнюю информацию злоумышленникам.

Итак: та же самая ошибка, в режиме отладки:

[[Файл:sql_error_and_stack_trace.png]]

Как это сделать: открываем sp.conf, пишем:
<pre>
DEBUG = 0
</pre>

Теперь все сообщения об ошибках обращения к базе будет с дампом запроса и стектрейсом (функции '''error''' и '''stop''' тоже поднимут стектрей), кроме того, светру над меню вы увидите служебную информацию и времени выполнения скрипта (при отсутствии ошибки итоговое, а при наличии стопа или ошибка время от начала до ошибки), количество SQL-запросов и текст всех запросов по клику на их количестве.

Здорово, правда? :)

Поехали дальше.

== Разделение на выдачу контента и принятие формы ==

Приведённый ниже код с учётом формы отправки сообщения пока не затрагивает вопрос поведения модуля в админке — мы всё ещё занимаемся частью кода для сайта.

<source lang="perl">
sub guestbook()
{
	if ( defined param('edt') ) # админка
	{
		print "Hello, admin interface!";
	}
	else # сайт
	{
		# Получить данные
		if ( $ENV{'REQUEST_METHOD'} eq 'GET' )
		{
			my $q = sqlp("select * from guestbook where published = 1 and owner = $owner");
			my %hash; $q->bind_columns( \( @hash{ @{$q->{NAME_lc} } } ));
			my $messages = '';

			while ($q->fetch)
			{
				$messages .= qq[
					<p>Имя: $hash{name}</p>
					<p>Дата: $hash{post_date}</p>
					<p>Сообщение: $hash{text}</p>];
			}
			return "<h2>Сообщения</h2>$messages";
		}
		# Записать данные
		elsif ( $ENV{'REQUEST_METHOD'} eq 'POST' )
		{
			my $name = param_dexss_lim('name', 128);
			my $text = param_dexss_lim('text', 1500);
			sqlb("INSERT INTO GUESTBOOK
				(NAME, TEXT, POST_DATE, published, owner)
				VALUES
				(?,    ?,    NOW()),    0,         $owner",
				$name, $text
			);
			return "Данные записаны.";
		}
	}
}
</source>

Что нового в коде: есть две ветки. Одна читает из базы (формируя HTML-вёрстку), другая пишет в базу принятое из формы и сообщает, что "Данные записаны.".

== Шаблоны ==

TODO: tpl tpl_str

== Админка ==

TODO