1564
правки
Изменения
Нет описания правки
*'''PaymentServices''' – платежный сервер.
*'''OrderServices''' – сервер заказов.
== Структура модуля ==
Модуль состоит из следующих папок и файлов:
*Event/ – каталог классов с событий и обработчиков;
*Controller/ – каталог размещения контроллеров панели управления и сервисов;
*Model/ – бизнес логика приложения и модели предметной области;
*Source/ – классы уровня доступа к данным;
*configs/ – файлы конфигурации;
admin/ - каталог конфигурационных фалов форм
menu.php – добавление пунктов главного меню
*lang/ - переводы;
*migrations/ - дампы миграций БД по данному модулю;
*temoplates/ - html шаблоны модуля;
*bootstrap.php – загрузчик модуля;
*autoloader.php – правила для автозагрузчика. Как правило тут устанавливается что классы из Model не содержат это слово своем названии;
*routes.php – роуты, адресация страницы панели управления.
== Добавление нового модуля ==
Модули должны иметь ТОЛЬКО одностороннюю зависимость от других модулей - это значит, что модуль B может зависеть от модуля A, но при этом модуль A не должен «знать» о существовании модуля B. Зависимость модулей может выражаться в наследовании классов, расширении модулей списками, привязке к событиям, прямых обращениях к классам других модулей. Расширение модулей списками — парадигма проекта, позволяющая на основании списка в реестре настроек (Core_Registry) реализовывать фабрики, не прописывая жестко в коде перечислений, к примеру, поставщиков и их фабрик.
Условно такие списки хранятся в ветке «module», т.е. Core_Registry::instance('module').
Например, в классе модуля авиа Flights_Module есть список flights.factory, и для удобства определены методы, добавляющие в него фабрики и возвращающие список. При таком подходе в классе модуля произвольной GDS можно обратиться к модулю авиа и ддополнить фабрику этой GDS. Авиа модуль же, когда ему нужно получить нужную фабрику, просто обращается к этому списку и берет ее по имени сервиса. Таким образом, мы получаем дополнительные возможности по исключению взаимозависимостей в модулях.
'''Схема добавления нового модуля:'''
1) Создать каталог модуля в папке /modules, к примеру MyMod;<br>
2) Создать необходимые подкаталоги, как минимум Model;<br>
3) В папке Model добавить класс данного модуля — MyMod_Module в котором определим метод load. Этот метод вызывается при загрузке модуля и именно здесь нужно расширять списки других модулей, если требуется.<br>
4) Заполним файлы autoload.php и bootstrap.php. В autoload заносятся дополнительные правила для автозагрузчика. Сделаем так, чтобы папку Model не требовалось писать в имени класса:
<pre>$rules = array(
'MyMod' => 'MyMod_Model'
);</pre>
А в файл bootstrap пропишем параметры загрузки нашего модуля: его имя, его загрузчик и его зависимости от других модулей (к примеру, Core и Main):
<pre>$module = array(
'name' => 'MyMod',
'loader' => 'MyMod_Module',
'require' => 'Core,Main',
);</pre>
Модуль успешно создан.
== Добавление нового модуля сервера ==
Процесс схож с обычным добавлением модуля. В классе нашего модуля в методе load запишем добавление в список расширения базового модуля сервисов:
<pre>ServerKit::getContext()->getModule('Services')->addService('MyServices');</pre>
После этого автозагрузчик и генератор WSDL «увидят» классы и модели нового сервиса. Все веб-сервисные классы должны иметь версию, поэтому и в контроллерах и в моделях необходимо создать папку version/номер_версии/ и далее - нужные файлы. Версия по умолчанию - 1.0. Модели в веб-сервисах — это специальные классы с public полями и комментариями, по которым генерируется WSDL файл.
Полноценные наборы моделей состоят из нескольких элементов:
*Сервер с доступными методами.
*Ветка классов запроса.
*Ветка классов ответа.
Под cервером здесь понимается смысловой набор методов, посвященный одной теме (например, Поиск). Категории содержат группу серверов (к примеру, есть категория Отели, а в ней серверы поиска, дополнительной информации и т.д.).
'''Правила размещения:'''
БзкуЮModel/version/<номер версии>/<имя категории>/...</pre>
'''Внутри категории:'''
*Request / - ветки запросов
*Response / - ветки ответов
*.php классы описания серверов
Детальнее можно посмотреть на имеющихся примерах.
Внутри метода класса сервера обязателен код вида:
<pre>/**
* <Описание>
*
* @param <Тип оболочки запроса> $RequestBin
* @return <Тип оболочки ответа> $responseBin
*/
public function <Метод> ($RequestBin)
{
return parent::<Метод> ($RequestBin, new <Тип оболочки ответа> ());
}</pre>
Остальная логика ожидается в соответствующем контроллере/экшене.
Вызов этих методов клиентом происходим по имени. Список имен и соответствующих сеhверов/методов задается в файле
<pre>Model/version/<номер версии>/routes.php</pre>
Пример серверного модуля - MovieServices - размещен в ветке разработчиков.
== См. также ==