Изменения

[[Категория:Перенесенные статьи]]<!-- -->'''Модуль''' - — составная часть системы, функционально завершенная и обладающая независимыми характеристиками, что позволяет делить программу на фрагменты без потери ее целостности.

Система Nemo {{NameSystem}} состоит из модулей, что дает возможность подобрать только тот функционал, который действительно нужен клиенту.  == Список модулей системы 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 - размещен в ветке разработчиков.

* [[Сервер]]<br>* [[Панель управления]]<br>* [[Бронирование]]<br>* [[Сейбр]]<br>* [[Галилео]]<br>* [[ГТА]]<br>* [[Хронопей]]<br>* [[Электронный билет]]<br>* [[Пассажир]]