|
|
| (не показаны 4 промежуточные версии 3 участников) |
| Строка 1: |
Строка 1: |
| | [[Категория:Термины]] | | [[Категория:Термины]] |
| − | '''Модуль''' - составная часть системы, функционально завершенная и обладающая независимыми характеристиками, что позволяет делить программу на фрагменты без потери ее целостности. | + | [[Категория:Перенесенные статьи]] |
| | + | <!-- --> |
| | + | '''Модуль''' — составная часть системы, функционально завершенная и обладающая независимыми характеристиками, что позволяет делить программу на фрагменты без потери ее целостности. |
| | | | |
| − | Система 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> | + | * [[Электронный билет]] |
| − | [[Пассажир]] | + | * [[Пассажир]] |
