Система Nemo состоит из модулей, что дает возможность подобрать только тот функционал, который действительно нужен клиенту.
== Список модулей системы Nemo ==
*Ядро системы: служба авторизации и управления пользователями, панель управления.
*Стандартный интерфейс к поиску и бронированию авиабилетов с использованием технологии GDS Sabre — LowFareSearch (LFS).
*Модуль поиска авиабилетов с использованием технологии GDS Sabre — BargainFinderMax (BFiM).
*Модуль автоматической выписки электронного билета BSP (e-Ticketing) в GDS Sabre.
*Модуль поиска и бронирования авиабилетов в GDS Galileo.
*Модуль по продаже билетов авиакомпаний-дискаунтеров (LowCost).
*Модуль выбора места при бронировании (Seat Mapping).
*Модуль внесения данных карты лояльности постоянного пассажира при бронировании (Loyalty Card).
*Шлюз к Gulliver's Travel Associates — интерфейс по поиску и бронированию отелей, трансферов и экскурсий из системы GTA.
*Справочник: «Гео-объекты».
*Справочник: «Отели».
*Справочник «Аэропорты».
*Справочник «Авиакомпании».
*Справочник «Типы воздушных судов».
*Модуль «Корзина покупателя».
*Модуль динамического пакетирования (DynaPack).
*Шлюз по приему онлайн оплаты к UFS.
*Шлюз по приему онлайн оплаты к Chronopay.
== Основные модули системы в версии Nemo 2.0 ==
*'''Core, Main''' – базовые модули, содержащие самые общие для всех серверов объекты и действия. В них входят работы с формами, подключение к БД, [[логирование]], работа со списками, [[панель управления]] и т.д. Core в отличие от Main содержит системный код, вроде подключений к БД. Main – общие для всех серверов элементы бизнес логики, страницы панели управления.
*'''Zend''' – модуль содержит библиотеки Zend Framework. В частности, в проекте используется генерация WSDL на основе механизмов ZendAutoDiscover.
*'''Services''' – базовый модуль для построения сервиса. Именно его функциональность необходимо расширять при создании своего сервиса.
*'''Schemas''' – WSDL модели общие для всех серверов по бронированию услуг. Содержит схемы объектов перелетов, отелей, их бронирований и т.д. Используется в паре с модулем конкретного сервера.
*'''Flights''' – модуль работы с авиа-перелетами. Кроме описание авиа-объектов, содержит логику по основным действиям авиа.
*'''Hotels''' – модуль работы с отелями — отельные объекты и действия над ними.
'''Модули GDS, WBS''' – модули добавляют себя в списки поставщиков Flights и Hotels и используются этими модулями для совершения действий.
*'''FlightsServices''' – сервер Авиа.
*'''HotelsServices''' – отельный сервер.
*'''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 - размещен в ветке разработчиков.
== См. также ==