Автоматическое формирование uri / запроса

[xnic]

Автоматическое формирование uri / запроса

Изначальное решение

Как мне известно, на этапе проектирования сайта составляется карта сайта. Она включает в себя:


1. Структуру видимых (и возможно невидимых) директорий.

2. Имена скриптов

3. Параметры скриптов с описанием и ограничениями



Далее, при кодировании, этой картой руководствуются при реализации сайта, для вставки ссылок (в шаблоны) на соответствующие скрипты.


Видимые мне недостатки такого решения:


1. Необходимо постоянно держать под рукой карту сайта (она отличается от диаграммы классов).

2. Очень трудоемки изменения в интерфейсах скриптов (при добавлении, например, параметра необходимо менять все ссылки на них вручную, следовательно, велика вероятность незамеченной ошибки).




Первый вариант решения проблемы (описан сокращенно):


1. Написан класс TDispatcher (статический), который отвечает за взаимное отображение uri <-> (имя_класса, параметры), где uri - строка запроса, имя_класса - имя класса для создания (наследник от TPage), параметры - список пар имя-значение для установки их в экземпляре класса.

class TDispatcher
{
    /* Получает uri страницы по имени класса-вида и параметрам */
    /* При отсутствии параметра берется параметр по умолчанию, если не установлен REQUIRE_PARAMS */
    static function GetUri(TPage $ClassName, $Params = array(), $Mode = TDispatcher::REQUIRE_PARAMS);
    /* Разбирает запрос, определяет класс, создает его экземпляр, устанавливает параметры */
    static function GetClass($Uri);
};

2. Написан базовый класс TPage, все страницы наследуются от него.

class TPage
{
    /* Параметры страницы, ассоцативный массив */
    private $Params;

    /* Получение параметра по имени */
    function __get($Name);
    
    /* Установка параметра по имени */
    function __set($Name, $Value);

    /* Инициализация параметра - должна быть вызвана в наследующем классе */
    /* т.к при отсутствии параметра в __get и __set в будет вызвано исключение */
    /* исключает ошибку типа "забыл поставить параметр" */
    protected function Init($Name, $Default);

    /* Получить данные со страницы */
    abstract function GetContent();
};

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



parameter - начальная часть uri, отделенная /, имеет порядок следования

variable - часть после ?

constant - заданная часть uri

Модель: /constant1/constant2/.../param1value/param2value/...?var1=var1value&var2=var2value...

Пример карты:

<?xml version="1.0" encoding="Windows-1251"?>
<!DOCTYPE sitemap>
<sitemap id="TDefault" xsi:noNamespaceSchemaLocation="interface\sitemap.xsd">
  <page id="TAboutPart" description="Общая информация о компании">
    <constant uri="about"/>
  </page>
  <page id="TCategoryPart" description="Каталог продукции">
    <constant uri="catalog" />
    <parameter name="id" description="Идентификатор каталога">
    <variable name="start" default="1" />
    <variable name="producer_id" default="" />
    <variable name="costfrom" default="" />
    <variable name="costto" default="" />
    <variable name="catalog_id" default="" />
    <variable name="sortby" default="title" />
    <variable name="order" default="ASC" />
  </page>
  <page id="TAdmIndex" description="Управление/Главная">
  <constant uri="adm">
    <page id="TAdmCatalog" description="Управление/Каталог продукции">
      <constant uri="catalog"></constant>
      ...
    </page>
  </page>

</sitemap>

Что получаем в результате первого решения:


1. Для вставки адреса (например, в шаблон) используется следующая конструкция (пример с главной страницы, выбираем в шаблон список каталогов):

$q = new TQuery('SELECT id, title FROM catalog WHERE active=1 ORDER BY order ASC);
$Uri = TDispatcher::GetUri('TCategoryPart', array('id'=>$q->id));

2. Все операции формирования адресов контролируются программно. (т.е уменьшается вероятность ошибки при кодировании).

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

1. Нет необходимости помнить карту сайта, вся необходимая информация содержится в описании классов.

2. При при изменении интерфейса система сама скажет, где что-то не так.

3. Изменение адреса страниц мгновенно






Недостатки схемы:


1. POST запросы остались за кормой.

2. Контролируется только наличие параметров, но не их содержимое (дальнейший контроль производит класс-обработчик).




Вопросы:


1. Есть ли смысл дорабатывать схему в этом направлении? Или может отказаться от него?

2. Приветствуются любая критика, вопросы и обсуждение.

 

[ZN]

не вижу смысла так жестко связывать страницу с классом
>POST запросы остались за кормой
то есть вы хотите чтобы, кроме урлов, ещё и формы на страницах формировались автоматически вашим диспетчером?
>Контролируется только наличие параметров, но не их содержимое (дальнейший контроль производит класс-обработчик).
а как вы хотите переложить задачу контроля параметров на диспетчер, который только формирует ссылки? у хорошо, я проконтролирую, чтобы мой диспетчер, который я сам написал, выдавал только ссылки с правильными параметрами и на страницах появлялись только такие ссылки - а потом приходит зло-вася, и тыкает не на ссылку, которая сформирована моим диспетчером, а сам формирует ссылку - вы всё ещё хотите обойтись без "дальнейшего контроля в классе-обработчике"?