Таблица “Pages” состоит из следующих полей:

• id – идентификатор страницы (ключевое поле);
• pid – идентификатор родителя;
• name – имя страницы (используется для отображения в меню);
• hide – булева переменная отображения страницы;
• access – уровень доступа;
• sort – приоритет при формировании меню;
• left – ориентация выпадения меню;
• title – заголовок страницы;
• keywords – ключевые слова;
• description – описание;
• content – содержимое страницы.

 

      Таблица “Capcha” состоит из следующих полей:

• id (идентификатор капчи – ключевое поле)
• dig (значение капчи)
• time (время показа капчи)
• ip (IP адрес для которого генерировалась капча).

 

      Таблица “Group” состоит из следующих полей:

• gid (идентификатор группы – ключевое поле)
• name (имя группы)
• users (пользователи принадлежащие данной группе).

 

      Таблица “IPBlock” состоит из следующих полей:

• addr (IP адрес – ключевое поле)
• count (счетчик – при достижении предопределенного значения IP блокируется)
• etime (время по достижению которого запись удаляется)
• blocked (кто заблокировал IP: авто или логин пользователя)
• reason (причина блокировки)

 

      Таблица “User” состоит из следующих полей:

• user (логин пользователя – ключевое поле)
• pass (зашифрованный пароль пользователя)
• ctime (время создания учетной саписи)
• stime (проведено времени)
• ltime (время последнего входа)
• laddr (IP адрес последнего входа)
• stotal (количество успешных заходов)
• param (другие параметры пользователя)

 

      Таблица “UserBlock” состоит из следующих полей:

• user (логин пользователя – ключевое поле)
• count (счетчик – при достижении предопределенного значения логин пользователя блокируется)
• etime (время по достижению которого запись удаляется)
• blocked (кто заблокировал IP: авто или логин пользователя)
• reason (причина блокировки)

 

    Таблица “Session” состоит из следующих полей:

• id – идентификатор сессии;
• user – логин пользователя сессии;
• addr – IP адрес пользователя сессии;
• etime – время по наступлении которого удаляется текущая сессия;
• atime – время последней активности пользователя в данной сессии;
• ctime – время создания текущей сессии.

 

      Тщательная  разработка файловой структуры облегчает в дальнейшем его модернизацию и поддержку, а также играет большое значение, при его размещении в Интернет в планах корректности работы [16, c.45].

      На  рис. 2.5 приведена структура файловой организации разработанной CMS,

Рис. 2.5 Файловая структура  разработанной CMS.

где:

• usmtabak.ru – домашняя директория сайта;
• cgi-bin – директория cgi-скриптов, здесь находятся вся программная реализация разработанной CMS;
• config – директория с настройками CMS;
• lib – директория с библиотеками используемой CMS;
• module – директория с модулями расширяющих базовую функциональность CMS;
• www – корневая директория сайта;
• css – директория каскадных таблиц стилей;
• images – директория с картинками;
• upload – директория для загрузки картинок через визуальный редактор;
• js – директория с Java-скриптами используемых CMS;
• ckeditor – Java-скрипты библиотеки визуального редактора CKEditor;
• imglib – Java-скрипты библиотеки работы с изображениями;
• templates – директория содержащая шаблоны отображения страниц используемых в CMS;
• default – шаблон используемый по умолчанию.

 

Глава 3. Программная реализация

3.1 Ядро сайта

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

1. Получение данных от пользователя.
2. Подключение к СУБД.
3. Создание дерева зависимостей страниц сайта и генерация меню.
4. Генерация ЧПУ (англ. Friendly URL) для страниц сайта.
5. Выборка данных из БД соответствующих запросу пользователя.
6. Подключение модулей расширения базового функционала.
7. Визуализация сгенерированных данных, посредством использования шаблона представления. И передача их пользователю.

 

      Получение данных от пользователя осуществляется путем их извлечения из переменных окружения, генерируемых. При передачи данных форм символы не входящие в “основную латиницу” кодируются в их наглядное шестнадцатеричное представление с вставкой перед ним знака ‘%’, к примеру символ ‘я’ в кодировке windows-1251, имеющий десятичный код 255, будет передан как ‘%FF’. Так же данные от пользователя могут приходить разными методами HTTP таких как GET и POST. Главным отличием метода POST – это то, что при работе браузера с Web-сервером в запросе кроме заголовков запроса передается также и тело запроса отделенное от заголовков пустой строкой. Тело запроса передается на стандартный вход программы (<STDIN>).

      При обработке входных данных шаблонизатор генерирует глобальные переменные доступные  всем подключаемым модулям и расширениям  CMS. В листинге 3.1 показано получение данных от пользователя. Из листинга можно заметить, что обработка переменной $ENV{'QUERY_STRING'} используемой при GET-запросе так же используется и при POST-запросе, связано это прежде всего с тем, что данные GET-запроса мы можем вставить непосредственно в поле action html формы или в поле href html ссылки отделив их от адреса документа знаком вопроса. 

Листинг 3.1.

#############################################################################

# Обявляем глобальные переменные 
our $in={}; # Анонимный хешь данных форм

#############################################################################  
{# Обрабатываем формы. 
sub urldecode($){# Процедура декодировния данных форм. 
    my $val=shift; 
    $val=~tr/\+/ /; 
    $val=~s/%([\dA-F]{2})/pack('C',hex($1))/eg; 
    $val; 
}

 
# Процедура считывания строки запроса в глобальный анонимный хешь $in. 
sub query2in($){ 
    my $query=shift; 
    foreach my $pair (split(/&/,$query)){# Разбиваем запрос на пары 
        my($n,$v)=map {urldecode($_)} split(/=/,$pair);#Декодируем пары 
        if(defined $in->{$n}){# Уже создана запись с данным иенем формы

                             # актуально для форм с множественным выбором

          # Если созданная запись не является анонимным массивом создаем его 
           $in->{$n}=[$in->{$n}] if ref $in->{$n} ne 'ARRAY';

          # Добавляем к анонимному массиву значение формы 
           push(@{$in->{$n}},$v); 
        }else{$in->{$n}=$v} # Добавляем форму и ее значение 
    } 
} 
query2in($ENV{'QUERY_STRING'});# Обработка GET запроса 
if ($ENV{REQUEST_METHOD} eq 'POST'){# Обработка POST запроса 
        read(STDIN,my $buffer,$ENV{'CONTENT_LENGTH'}); 
        query2in($buffer); 
    } 
} 

      Для подключения к СУБД в Perl используется модуль DBI предоставляющий единый интерфейс для работы с базами данных, что позволяет сделать конечный продукт независящим от диалекта конкретной СУБД, а значит переносимым (см. листинг 3.2), где:

$cfg->{sql}->{type} – драйвер СУБД, к примеру: mysql – MySQL, Pg – PostgreSQL, Oracle – Oracle и т.д.;

$cfg->{sql}->{name} – имя БД;

$cfg->{sql}->{host} – сервер СУБД, к примеру: localhost;

$cfg->{sql}->{user} – пользователь БД;

$cfg->{sql}->{pass} – пароль для доступа к БД.

Листинг 3.2.

# Подключаемся к  БД

# Создаем глобальный объект интерфейса DBI  
our $db=DBI->connect('DBI:'.$cfg->{sql}->{type}.':'

                       .$cfg->{sql}->{name}.':'

                       .$cfg->{sql}->{host},

                        $cfg->{sql}->{user},

                        $cfg->{sql}->{pass});

# Если не удалось создать объект выводим сообщение об ошибке 
die "Error $DBI::err \"$DBI::errstr\"." unless $db; 

      Создание  дерева зависимостей страниц сайта на первый взгляд непростая задача, так как в MySQL (именно эта СУБД предоставляется на большинстве хостинговых площадок) нет встроенного инструмента для работы с деревьями, придется генерировать их программно средствами Perl. Для генерации дерева сразу напрашивается процедура с рекурсией, запрашивающая в БД, для начала, страницы принадлежащие корневому разделу (корневому раздел в нашей CMS мы присвоили id=0), а потом для каждого дочернего раздела вызывала сама себя для поиска уже их детей, тем самым формируя дерево. Сложно представить сколько запросов придется сделать, если страницы сайта имеют большой уровень вложенности, при этом для генерации дерева зависимостей нам, в любом случае, придется считать значения колонок ‘id’ и ‘pid’ всей таблицы. Поэтому, с точки зрения производительности системы нам проще считать все зависимости в одном SQL-запросе, программно составить два ассоциативных массива(хэшей) id=pid и pid=id, а потом рекурсивной процедурой пройти по хэшу pid=id, передавая в качестве значения  дочерних разделов хэш id=pid, строить дерево. Казалось бы других решений нет, но Perl позволяет создавать ссылки на все типы переменных, что позволяет нам построить дерево зависимостей в один проход, при этом мы получаем очень удобную структуру данных позволяющую обратится к элементу по его id в независимости от его уровня вложенности, что было реализовано в процедуре get_pages (см. листинг 3.3).