Opencart

Статья нашего сотрудника из его личного блога.

Разрабатывая модуль, в админке мне понадобилось использоватьмодальные окна OpenCartдля вывода определенной информации, а так же для показа формы. Мой опыт frontend на тот момент былтак себе, однако коллега подсказал что в OpenCart используется jquery(2.1.1), а у этой библиотеки есть поддержка popup окон. Но не все так просто

Уточним: модальное окно == всплывающее окно == popup.

Библиотека модальных окон

Для того чтобы использоватьмодальное окно OpenCart, надо определитькакая библиотекапредоставляет для этого функционал, используемый в этом движке. Разбирая админку OpenCart 3.0(в 2.3 такой кнопки нет), в разделеПанель состояниябыла найдена кнопка, при клике по которой показалосьвсплывающее окно.

То что нужно, начинаем разбор :)

Заходим на страницу "Панель состояния", открываем ее исходный код и смотрим в конце скрипт:

$('#button-setting').on('click', function() {    $.ajax({        url: 'index.php?route=common/developer&user_token=D9aTD65JQVdyOY9pcVxcRUx0M3eTefnr',        dataType: 'html',        beforeSend: function() {            $('#button-setting').button('loading');        },        complete: function() {            $('#button-setting').button('reset');        },        success: function(html) {            $('#modal-developer').remove();                         $('body').prepend('<div id="modal-developer" class="modal">' + html + '</div>');                         $('#modal-developer').modal('show');        },        error: function(xhr, ajaxOptions, thrownError) {            alert(thrownError + "\r\n" + xhr.statusText + "\r\n" + xhr.responseText);        }    }); }); 

Как видно, на кнопку с idbutton-settingвешается обработчик на клик, в которомajax запрос, успешный результат которого показывается вpopup окне. А для показа этого окна используется:

$('#modal-developer').modal('show');

Похоже на библиотеку jquerymodal. Однако в bootstrap тоже есть поддержка модальных окон. Пробуем выяснить через отладчик какая библиотека все-таки используется,ставим брекпоинтв вышеприведенном скрипте на методеmodal.

Нажимаем на кнопку(на первом скрине), попадаем на брекпоинт, шагаем внутрь и попадаем вbootstrap.min.js.

Всплывающие окна в OpenCartреализуются через bootstrap.

Использование popup окон в OpenCart

Проинспектировав окновыясняем что оно уже содержит нужную нам логику закрытия окна и состоит из двух важных для нас частей:

• divс классомmodal-headerв которомh4, который и есть заголовок окна

• divс классомmodal-bodyC11Cвнутри содержит контент окна

Так как окно уже имеет оформление, то просто возьмем его каркас, классы и на основе верстки этого окна составим свое:

<div id="modal-window" class="modal">    <div class="modal-dialog">        <div class="modal-content">                       <!--заголовок и кнопка закрытия-->            <div class="modal-header">                <button type="button" class="close" data-dismiss="modal" aria-hidden="true"></button>                <h4 class="modal-title"></h4>            </div>                         <!--контентная часть окна-->            <div class="modal-body"></div>                     </div>    </div></div>

Для показа окна с idmodal-windowбудем использовать:

$('#modal-window').modal('show');

Теперь в нужном нам месте страницы в админке разместим свои вёрстку и js. Для этого используем события в OpenCart. Например повесим обработчик на страницу редактирования заказа:

$this->model_extension_event->addEvent('modal_window', 'admin/view/sale/order_form/after', 'extension/module/modal_window/eventSaleOrderFormAfter');

Теперь обработчик:

public function eventSaleOrderFormAfter(&$route, &$args, &$output){    $idOrder = $args["order_id"];     $this->load->model('sale/order');    $this->load->model('catalog/product');     //загрузка списка продуктов заказа    $aOrderProducts = $this->model_sale_order->getOrderProducts($args["order_id"]);         //строка верстки списка товаров    $sOrderProducts = "";     //формируем список товаров    for($i=0; $i<count($aOrderProducts); ++$i)    {        $aProduct = $this->model_catalog_product->getProduct($aOrderProducts[$i]["product_id"]);        $sOrderProducts .= "<li>".$aProduct["name"]." - ".$aProduct["model"]." (".$aOrderProducts[$i]["quantity"]." шт.): ".round($aOrderProducts[$i]["total"], 2)."р. </li>";    }         $sOrderProducts = "<ul>$sOrderProducts</ul>";     //верстка модального окна и скрипт вызова    $sModal = '    <div id="modal_window" class="modal">        <div class="modal-dialog">            <div class="modal-content">                <div class="modal-header">                    <button type="button" class="close" data-dismiss="modal" aria-hidden="true"></button>                    <h4 class="modal-title">Список товаров</h4>                </div>                <div class="modal-body">                    '.$sOrderProducts.'                </div>            </div>        </div>    </div>    <script>$("#modal_window").modal("show");</script>    ';     //находим закрывающий тег body и перед ним вставляем модальное окно и скрипт его показа    $iPos = strripos($output, "</body>");    $output = substr($output, 0, $iPos).$sModal.substr($output, $iPos);}

Каждый раз при входе на страницу редактирования заказа будет появляться всплывающее окно со списком товаров.

Можно вставлять кнопку в панель кнопок в админке(или в любое другое место), повесить на кнопку обработчик клика и показывать модальное окно(как это сделано на страницеПанель состояния). Однако для этого придется использовать регулярные выраженияили парсер DOM.

Автор: Виталий Бутурлин

В статье рассмотрим как устроеныajax запросы в OpenCart, в том числе запросы черезapi OpenCart, познакомимся с новым понятиемfront controllerи немного коснемся темыajax REST API.

Клиент

Клиентская часть OpenCart работает с использованиемjquery, а значит можно использовать$.ajaxиз этой библиотеки.Ссылка на документацию. Примеры ajax запросов на клиентской части можно посмотреть вadmin/view/template/sale/order_form.tpl_{(.twig для OpenCart 3.0).}

Сервер

Просматривая все тот же файлadmin/view/template/sale/order_form.tpl(для OpenCart 2.3)можно понять, чтов качестве адреса вызова используется классическая схема роутинга OpenCart. Посмотрим на один из запросов:

$.ajax({    url: 'index.php?route=customer/customer/autocomplete&token=<?php echo $token; ?>&filter_name=' +  encodeURIComponent(request),    ...

Все просто:url - путь до контроллера и, если надо,имя метода этого контроллера.

То есть, нам нужносоздать класс контроллера, затем из файлов представления можновызывать методы этого контроллераajax запросами.

Создадим контроллер нашего нового тестового модуля по путиadmin/controller/extension/module/myajax.php:

class ControllerExtensionModuleMyAjax extends Controller{    public function index()    {        $this->response->addHeader('Content-Type: application/json');        $this->response->setOutput(json_encode(            [                "success" => true,                 "message" => "ok",                 "data" => []            ]        ));    }}

В классе контроллера есть объектresponse, это экземпляр классаResponse, который расположен по путиsystem/library/response.php. Он позволяет управлять ответом сервера. Нас интересуют только 2 метода:

• addHeader($header)- добавить http заголовок,headerстроковый аргумент

• setOutput($output)- установить данные для вывода,outputстроковый аргумент

Для формирования ответа на запрос в методе контроллера можно использовать-

$this->response

Так как OpenCart имеет 2режима доступа/контекста(admin, catalog), то передаваемые данные в запросах разные:

• admin- требует токен вgetпараметре(получить можно из объекта класса контроллера):

  • для OpenCart 2.3token, который берется из$this->session->data['token']

  • для OpenCart 3.0C4C, который берется изC14CC5C

• catalog- в общем случае не требует токена, но есть нюансы о которых позже

Теперь чтобы осуществитьajax запросдостаточно в файл представления(читай в html)подставить js(код для OpenCart 2.3):

$.ajax({    url: '<?php echo $admin; ?>index.php?route=extesion/module/myajax&token=<?php echo $token; ?>',    type: 'get',    dataType: 'json',    success: function(json) {        alert("success: "+json["success"]+"\n"+"message: "+json["message"]);    },    error: function(xhr, ajaxOptions, thrownError) {        alert(thrownError + "\r\n" + xhr.statusText + "\r\n" + xhr.responseText);    }});

В этом коде в urladminэто путь указывающий контекст запроса(admin или catalog). Для контекста есть 2 дефайна, определенных вadmin/config:

• HTTP_SERVERилиHTTP<b style="box-sizing: border-box;">S</b>_SERVER- путь до директорииadmin(проще - админка), где будет осуществлен поиск контроллера для выполнения запроса

• HTTP_CATALOGилиC6CC15C- корень сайта, однако контроллеры будут браться из директорииC16CC7C

Ajax API

Просматривая файл представленияadmin/view/template/sale/order_form.tpl(OpenCart 2.3), можно увидеть что из админки осуществляются ajax запросы наcatalogконтекст, с использованием особого токена.

Сначала объявляется глобальная переменнаяtoken, затем ajax запрос на адрес/index.php?route=api/login, который отвечает json данными, в которых есть ключtoken:

var token = ''; // Login to the API$.ajax({    url: '<?php echo $catalog; ?>index.php?route=api/login',    type: 'post',    data: 'key=<?php echo $api_key; ?>',    dataType: 'json',    crossDomain: true,    success: function(json) {    //...         if (json['token']) {            token = json['token'];        }    },    error: function(xhr, ajaxOptions, thrownError) {        alert(thrownError + "\r\n" + xhr.statusText + "\r\n" + xhr.responseText);    }});

Контроллер этого запроса находится вcatalog/controller/api/login.php ControllerApiLogin::index. Он:

• создает новую сессию

  (catalog/model/account/api.php - ModelAccountApi::addApiSession) и

• генерирует для нее случайный токен(функцияtokenнаходится вsystem/helper/general.php),

который возвращается в json этого ajax запроса, если доступ по api(api_key)разрешен для текущего пользователя(Админка-Система-API).

Дальше разбирая представлениеadmin/view/template/sale/order_form.tplможно увидеть, что последующиеajax запросы, которые по адресуroute=api/...используют этот самыйtokenдля определения права доступа, таким образом(в каждом api файле, в каждом методе)C25C существует такой кусок кода для определения права осуществлять запрос:

if (!isset($this->session->data['api_id'])) {    $json['error']['warning'] = $this->language->get('error_permission');} else {    ...}

Ajax запросы черезcatalogконтекст можно осуществлять с использованиемtokenдля безопасного доступа

А теперь копнем глубже и выясним, как это происходит внутри движка, ведь можно отправлятьajax запросыи без токена.

Просматривая код файлаindex.phpотправляемся вsystem/startup.php, оттуда следуем вsystem/framework.phpв самый конец и видим такое вот:

// Front Controller$controller = new Front($registry); // Pre Actionsif ($config->has('action_pre_action')) {    foreach ($config->get('action_pre_action') as $value) {        $controller->addPreAction(new Action($value));    }}

Здесь видим новое понятиеfront controller, код которого находится вsystem/engine/front.phpв классеFront.

Ниже следует мое субъективное определение этого понятия :)

Подробных комментариев найти не удалось, но судя по кодуfront controllerэтоглавный/передний контроллер, онзапускает общий контроллерstartup/routerотносительно директорииcontrollerконтекста(admin/controllerилиcatalog/controller), которыйвыполняет первичные контроллеры,указанные в$_['action_pre_action'];в файлеsystem/config/catalog.php.

В коде выше происходит только добавление первичных контроллеров воfront controller, а их исполнение осуществляется кодом ниже, в методеdispatch(внутри метода перед выполнением action указанного в$config->get('action_router')):

// Dispatch$controller->dispatch(new Action($config->get('action_router')), new Action($config->get('action_error')));

Среди первичных контроллеров естьstartup/sessionотносительноcatalog/controller, где вControllerStartupSession::indexнаходится интересующий наскод для авторизации в api через токен. Вкратце:

• происходит проверка обращения кapi/и наличияgetпараметраtoken

• удаление старых api сессий

• выборка актуальной api сессии на основании ip адреса запросившего и его токена

• старт сессии с id из$_COOKIE["api"]

• обновление времени модификации сессии, (чтобы она осталась жива, то есть не была устаревшей)

Теперь, когда исполнение кода дойдет до целевого контроллера,$this->session->data['api_id']уже будет инициализировано, если указана актуальная комбинация токена и ip адреса.

Ajax REST API

_{Данная глава описывает возможный вариант создания и встроенные средства реализации REST API в OpenCart.}

Мы рассмотрели реализациюajax запросов OpenCartдляadminиcatalogконтекстов.

Если говорить обadmin, то предполагается более рациональным реализовывать контроллеры именно вadminконтексте. Однако, такое не всегда возможно. Иногда один и тот же код контроллера(возможно речь о методе контроллера)должен использоваться в обработчикеcatalogсобытия(например при изменении заказа), так и отдельно непосредственно при работе с заказом через админку. Чтобы устранить такие случаи можно реализовать контроллеры вcatalogконтексте и организовать для нихбезопасный доступ(о чем говорится в предыдущей главе).

Для реализацииREST API в OpenCartесть все необходимое:

• объект для работы с ответом сервера в контроллере$this->response, а именно методыaddHeaderиsetOutput

• безопасная работа с административным доступом черезcatalogC22Cконтекст

• единая точка входа api черезC24CC10CC25C контекст, в директориюC26CC11CC27C, можно размещать свои файлы контроллеров и при помощи ajax осуществлять к ним запросы

На стороне сервера надосоздать контроллерывcatalog/controller/api/, а на стороне клиентадобавить ajax запросы в нужные файлы представленийс использованием токена, полученного в результате ajax запросаapi/login. Если в этих файлах нет такого ajax запроса, тогда необходимо добавить его, например, взяв изadmin/view/template/sale/order_form.tpl.Теперь чтобы сделать REST API достаточно изучить, что это такое, несколько ссылок:

• https://ru.wikipedia.org/wiki/REST

• http://personeltest.ru/aways/habr.com/ru/post/483202/

Автор: Виталий Бутурлин

Статья нашего разработчика из его личного блога.

Разрабатываямодуль для OpenCart, возникла необходимость сделатьпроизвольное поле в карточке товара, которое должно быть виднотолько в админке. Это должно быть поле слогическим значением"маркирован товар или нет". Вот так в итоге:

Недолго поковыряв админку выяснил, чтоиз коробкиOpenCart не поддерживает кастомные поля, однако есть платные модули, например,вот. Значит нужно сделать кастомное поле в OpenCart самому.

Варианты решения задачи:

• заюзать неиспользуемые поля(sku, upc, ean, jan, isbn, mpn)-почти мгновенно, но возможно кто-то из наших клиентов будет использовать занятое нами поле.

• вмешаться в код движка-быстро и мало кода, однако тогда решение не переносимо и при обновлении движка придется обновлять и само решение, так как изменения будут потеряны при обновлении движка.

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

Для реализации дополнительного поля в карточке товара будем разрабатывать модуль ProductMarkedField. В общем схема выглядит так:

• изменить таблицу базы данныхпри установке модуля и прибраться в ней после удаления нашего модуля.

• показать дополнительное поле в карточке товарав админке OpenCart.

• сохранить полепри отправке формы

Последние два пункта должны быть выполнены при подписке на событияпоказа карточки товараиизменения товара.

Про детали разработки модулей для opencart поговорим в другой раз, а пока предположим что читатель имеет минимальный опыт в этом деле.

Основная логика модуля умещается в один файл контроллера admin/controller/extension/module/productmarkedfield.php. Для того чтобы модуль отобразился в разделе "Расширений"(чтобы его можно было инсталлировать/деинсталлировать)надо создать языковой файлadmin/language/ru-ru/extension/module/productmarkedfield.phpс таким содержимым:

<?php $_['heading_title'] = 'Кастомное поле в карточке товара "Маркировка"';

Установка модуля

В методе install нужномодифицировать таблицуproduct:

$this->db->query("ALTER TABLE `".DB_PREFIX."oc_product` ADD `marked` TINYINT UNSIGNED NOT NULL DEFAULT '0';");

В ocStore 2.3.x все нормально, но в ocStore 3.0.2.0 при использовании MySQL 8, запрос добавления нового столбца в таблицу заканчивался ошибкой:

Для решения этой проблемы изменим значение по умолчанию для столбца date_available:

$this->db->query("ALTER TABLE `".DB_PREFIX."product` CHANGE `date_available` `date_available` DATE NOT NULL;");

Теперь надо добавитьобработчики событий, чтобы с их помощью мы моглиизменять верстку карточки товараисохранять значение нашего дополнительного поля(для ocStore 2.3.x):

$this->load->model('extension/event'); //событие "после загрузки формы товара" - для показа дополнительного поля товара (обязательна маркировка или нет)$this->model_extension_event->addEvent(  'productmarkedfield', //код, в данном случае название модуля  'admin/view/catalog/product_form/after', //событие   'extension/module/productmarkedfield/eventProductFormAfter' //обработчик); //событие "после редактирования товара" - для сохранения статуса маркировки$this->model_extension_event->addEvent(  'productmarkedfield',   'admin/model/catalog/product/editProduct/after',   'extension/module/productmarkedfield/eventProductEditAfter');

Для ocStore 3.0.x модель событий загружается таким образом:

$this->load->model('setting/event');

И вместо объекта model_extension_event нужно использовать model_setting_event соответственно.

Дополнительное поле в карточке товара

Выводить наше поле в карточку товара мы будем после загрузкиadmin/view/template/catalog/product_form.twig. наш метод будет принимать 3 аргумента:

public function eventProductFormAfter(&$route,&$args, //переданные аргументы в этот шаблон&$output//html верстка страницы)

Нас интересует третий аргумент &$output, именно его мы и будем модифицировать вставляя туда верстку со значением нашего нового поля.

Для модификации формы нам понадобитсяSimple HTML DOM, икраткий мануал. Скачиваем и кладём его в system/library, а в коде подгружаем расположенный внутри класс таим образом(@ чтобы не выводить ошибки, так как оригинальная версия этой библиотеки загружается с некритичными ошибками):

@$this->load->library('simple_html_dom');

Затем используя регулярные выражения для того чтобы получить id товара.(Искал другие варианты, но id в нормальном виде в $args массиве не нашел):

preg_match("/product_id=(\d+)/", $args["action"], $aMatch);$idProdict = $aMatch[1];

Загружаем модель описывающую товар и получаем необходимую информацию о товаре(данные из таблиц product и product_description):

$this->load->model('catalog/product');$aProduct = $this->model_catalog_product->getProduct($idProdict);

Теперь мы имеем доступ к данным товара, среди которых наше дополнительное поле - значение маркировки.

Однако, этот код будет работать только для редактирования уже существующего товара, но при создании нового товара будут ошибки, так как не будет найден id еще несуществующего товара. Изменим вышеприведенный код:

$isMarked = false;if(preg_match("/product_id=(\d+)/", $args["action"], $aMatch)){    $idProduct = $aMatch[1];    $this->load->model('catalog/product');    $aProduct = $this->model_catalog_product->getProduct($idProduct);    $isMarked = $aProduct["marked"];}

То есть мы создали новую переменную isMarked, которая будет хранить в себе значение по умолчанию false и если удастся найти id товара, тогда в isMarked будет записано значение из нашего произвольного поля в карточке товара.

Теперь при помощи Simple HTML DOM найдем вкладку "Данные" и вставим в самое начало наше поле маркировки, предварительно подсмотрев на верстку необходимого gui элемента вadmin/view/template/catalog/product_form.twig(в ocStore 2.3.x tpl расширение, и внутри нет Twig):

$html = str_get_html($output);$html->find('div#tab-data', 0)->innertext = '<div class="form-group">    <label class="col-sm-2 control-label">Маркирован</label>    <div class="col-sm-10">        <label class="radio-inline">            <input type="radio" name="marked" value="1" '.($aProduct["marked"] ? 'checked="checked"' : "").'>Да        </label>        <label class="radio-inline">            <input type="radio" name="marked" value="0" '.(!$aProduct["marked"] ? 'checked="checked"' : "").'>Нет        </label>    </div></div>' . $html->find('div#tab-data', 0)->innertext;

Код рабочего метода целиком:

public function eventProductFormAfter(&$route, &$args, &$output){    @$this->load->library('simple_html_dom');    $isMarked = false;    if(preg_match("/product_id=(\d+)/", $args["action"], $aMatch))    {        $idProduct = $aMatch[1];        $this->load->model('catalog/product');        $aProduct = $this->model_catalog_product->getProduct($idProduct);        $isMarked = $aProduct["marked"];    }         $html = str_get_html($output);    $html->find('div#tab-data', 0)->innertext =     '<div class="form-group">        <label class="col-sm-2 control-label">Маркирован</label>        <div class="col-sm-10">            <label class="radio-inline">                <input type="radio" name="marked" value="1" '.($isMarked ? 'checked="checked"' : "").'>Да            </label>            <label class="radio-inline">                <input type="radio" name="marked" value="0" '.(!$isMarked ? 'checked="checked"' : "").'>Нет            </label>        </div>    </div>' . $html->find('div#tab-data', 0)->innertext;    $output = $html->outertext;}

Сохранение значения дополнительного поля

Для сохранения результатов в момент когда администратор нажимает кнопку "Сохранить", необходимо вручную(с помощью обработчика события)внести изменения в базу данных, так как модель catalog/product при редактировании товара(ModelCatalogProduct::editProduct)сохраняет только определенный набор данных, и наше новое поле не входит в этот набор.

Для этого мы уже зарегистрировали ранее обработчик события "после редактирования товара":

public function eventProductEditAfter(&$route, &$args){  //в $args[0] лежит id товара  $sSql = "UPDATE " . DB_PREFIX . "product SET marked = " . $this->db->escape($args[1]['marked']) . " WHERE product_id = '" . (int)$args[0] . "'";  $this->db->query($sSql);}

Удаление модуля

При деинсталляции модуля надо удалить столбец marked из таблицы product и удалить обработчики событий, установленные нашим модулем. Все это делается в методе uninstall.

Удалить столбец из таблицы товаров:

$this->db->query("ALTER TABLE `".DB_PREFIX."product` DROP `marked`");

Удалить все сообщения (для ocStore 2.3.x):

$this->load->model('extension/event');$this->model_extension_event->deleteEvent('productmarkedfield');

Удалить все сообщения (ocStore 3.0.x):

$this->load->model('setting/event');$this->model_setting_event->deleteEventByCode('productmarkedfield');

Послесловие

В целом не так уж и трудно, однако кажется немного странным тот факт, что верстку надо менять руками, так как нет удобного встроенного инструмента для изменения интерфейса.

Для тех, кто дочитал до конца -ссылкана архив с исходным кодом модуля.

Автор: Виталий Бутурлин

Источник

Статья нашего сотрудника из его личного блога.

В статье речь идет об OpenCart версии> =2.3, а именно рассматриваются 2.3 и 3.0

Система событий в OpenCart достаточно интересна, она не является заранее предопределенным списком событий. Внутренность движка устроена таким образом, что почти каждый метод контроллера, который реагирует на определенный роут, загружает какие-то файлы(другие контроллеры, модели, представления, переводы).

Система событий OpenCart это генерируемые события до и после загрузки файлов движка/модулей.

Например, рассмотрим контроллерadmin/controller/catalog/product.phpу которого на адрес/admin/index.php?route=catalog/productбудет вызван методindex:

public function index() {    $this->load->language('catalog/product');     $this->document->setTitle($this->language->get('heading_title'));     $this->load->model('catalog/product');     $this->getList();}

В этом методе используется загрузка файла перевода и моделиcatalog/product, и на оба факта загрузки можно установить свои обработчики изменяющие данные.

Какие события есть в OpenCart 2.3+?

Как мы определили ранее, заранее определенного списка событий нет. Однако предполагаемые события можно узнать в файлеsystem/engine/loader.php.$this->loadи есть объектLoader.

Просматривая файл можно увидеть что события генерируются ($this->registry->get('event')->trigger) при загрузке:

• контроллеров

• моделей

• представлений

• конфигов

• переводов

Нас интересуют не все объекты. Так как OpenCart построен по MVCl архитектуре, то в нем есть 4 вида загружаемых файлов, на основании загрузки, которых можно изменить/добавить логику движку. MVCl вкратце:

• Model - файлы моделей, те что работают с БД,admin/modelилиcatalog/model

• View - файлы представлений, интерфейс/верстка,admin/viewилиcatalog/view

• Controller - файлы обработчики роутов(путей по которым админы ходят в админке, а клиенты в клиентской части),admin/controllerилиcatalog/controller

• language - файлы переводов,admin/languageилиcatalog/language

При загрузке каждого такого объекта(кроме конфигов)движка генерируются события:

• before- до загрузки

• after- после загрузки

То есть, мы можем изменить(или вообще заменить, но об этом позже)логику при загрузке файла.

Логика работы событий

В момент, когда мы открываем страницу админки, или клиент просматривает товар, или со страницы сайта происходит ajax запрос, движок запускает первый контроллерstartup/router, который в свою очередь на основании get параметраrouteвыполняетactionцелевого контроллера(путь которого указан в route).

Однако, контроллерstartup/routerне выполняет загрузку через$this-> load, а самостоятельно генерирует событиеbefore, получая от него результат, и если этот результатnull, тогда целевой контроллер будет выполнен и наступит событиеafter(куcок кода изadmin/controller/startup/router.phpOpenCart 3.0):

// Trigger the pre events$result = $this->event->trigger('controller/' . $route . '/before', array(&$route, &$data)); if (!is_null($result)) {    return $result;} // We dont want to use the loader class as it would make an controller callable.$action = new Action($route); // Any output needs to be another Action object.$output = $action->execute($this->registry);  // Trigger the post events$result = $this->event->trigger('controller/' . $route . '/after', array(&$route, &$data, &$output)); if (!is_null($result)) {    return $result;} return $output;

Иными словами,

OpenCart 2.3+ позволяет полностью переопределить поведение запроса приbeforeилиafterсобытии.

Для загрузчиков файлов действует другая логика.

Если в событииbeforeодин из обработчиков возвращает неnull, тогда загрузка файла не будет происходить, ивместо результата загрузки файлабудетрезультат выполнения обработчика, вернувшего неnull. При этом событиеafterбудет сгенерировано и если один из обработчиков вернет неnullтогда результат его работы заменит предыдущий. Это можно увидеть на примере загрузки контроллера (основная логика аналогична и для представлений/моделей/переводов):

public function controller($route, $data = array()) {  // Sanitize the call  $route = preg_replace('/[^a-zA-Z0-9_\/]/', '', (string)$route);     // Keep the original trigger  $trigger = $route;     file_put_contents($_SERVER['DOCUMENT_ROOT']."/loader-controller.txt", $trigger."\n", FILE_APPEND);     // Trigger the pre events  $result = $this->registry->get('event')->trigger('controller/' . $trigger . '/before', array(&$route, &$data));     // Make sure its only the last event that returns an output if required.  if ($result != null && !$result instanceof Exception) {    $output = $result;  } else {    $action = new Action($route);    $output = $action->execute($this->registry, array(&$data));  }     // Trigger the post events  $result = $this->registry->get('event')->trigger('controller/' . $trigger . '/after', array(&$route, &$data, &$output));     if ($result && !$result instanceof Exception) {    $output = $result;  }     if (!$output instanceof Exception) {    return $output;  }  }

Любой из обработчиков событияbeforeилиafter, может переопределить результат выполнения события.

Вsystem/engine/event.php Event::triggerопределено: если какой-либо обработчик события(вbeforeилиafter)возвращает неnull, тогда после него не будут запущены другие обработчики этого события(дляbeforeилиafter).

Аргументы обработчиков событий

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

Аргументы событий передаются по ссылке, а значит изменения значений аргументов будут видны во всех местах где они используются. При загрузке MVCl файлов аргументы:

• приbeforeсобытии:&$routeи&$data

• приafterсобытии:&$route,&$dataи&$output

Описание аргументов(дополнительно можно посмотреть здесьsystem/engine/loader.php):

• &$routeсодержит данные о пути данного события, безcontroller|view|model|languageи безbefore|after, например, для событияcatalog/model/checkout/order/addOrderHistory/afterв&$routeбудетcheckout/order/addOrderHistory

• &$dataсодержит массив данных для работы события(либо пустой массив), например, для файлов представления это данные для подстановки в tpl/twig файлах

• &$outputсодержит результат работы самого события(или обработчика, который определил возвращаемое значение), например, для файлов представления это обработанное содержимое файла представления

Для видов в&$dataпередается ассоциативный массив для использования в tpl/twig файлах видов. В&$outputверстка загруженного вида, где данные из&$dataуже вставлены. Изменения&$dataприbeforeсобытии могут не иметь смысла, так как данные уже обработаны. Это относится ко всем загружаемым файлам.

Изменять&$outputприafterсобытии представления можно различными способами, один из которых используя библиотеку Simple Html DOM.

Удаление данных из&$dataприbeforeсобытии может быть критичным для следующих обработчиков, а добавление данных может не иметь смысла если обработчики событий не знают этих данных!

Хранение обработчиков событий в OpenCart

Системные обработчики хранятся в php файлахsystem/config/admin.phpиsystem/config/catalog.phpв ассоциативном массиве$_['action_event'], где ключ это загружаемый файл, а значение обработчик. Как видно из ключей этого массива, вместо полного пути загружаемого файла, можно указывать * в качестве реакции "на все". Таким образом часть событий проходит через "движковые обработчики".

В OpenCart 3.0 появились приоритеты работы обработчиков(чем меньше значение, тем выше приоритет)и объекты моделей больше не обрабатываются "движковыми" обработчиками.

Пользовательские(от модулей)обработчики событий хранятся в БД в таблицеevent:

• event_id- идентификатор (автоинкремент)

• code- код обработчика, один и тот же код может быть у нескольких обработчиков, сюда записывается название модуля

• trigger- событие, например,admin/view/catalog/product_form/after- после загрузки формы товара

• action- обработчик, напримерextension/module/productmarkedfield/eventProductFormAfter

• status- включен или нет обработчик (1/0)

• sort_order- порядок сортировки (приоритет выполнения обработчика)

Добавление обработчиков событий

Работа с событиями заключается в:

• регистрации обработчиков событий при инсталляции модуля(методinstall)

• удалении всех обработчиков событий при деинсталляции модуля(методuninstall)

Обязательно надо удалять обработчики событий при удалении модуля, иначе движок будет запускать обработчики из модуля, а при отсутствии файлов удаленного модуля будет ошибка!

Для работы с событиями на стороне админки, для OpenCart 2.3 есть модельextension/event, а для OpenCart 3.0setting/event.

Метод регистрации в обоих версиях одинаковый, за исключением параметра$sort_order(кусок кода из моделиeventдля OpenCart 3.0):

public function addEvent($code, $trigger, $action, $status = 1, $sort_order = 0) {    $this->db->query("INSERT INTO `" . DB_PREFIX . "event` SET `code` = '" . $this->db->escape($code) . "', `trigger` = '" . $this->db->escape($trigger) . "', `action` = '" . $this->db->escape($action) . "', `sort_order` = '" . (int)$sort_order . "', `status` = '" . (int)$status . "'");     return $this->db->getLastId();}

Отличается только названием обращения к объекту, через который ведется регистрация.

Разберем значение аргументов:

• code- идентификатор группы обработчиков, обычно это название модуля

• trigger- обрабатываемое событие, напримерadmin/view/catalog/product_form/after

• action- контроллер обработчик события, например,extension/module/productmarkedfield/eventProductFormAfterэто путь до файла обработчика, относительно того контекста для которого устанавливается обработчик, при этом в указанном файле должен быть класс имя, которого формируется из

"Controller" . $sRelPath . $sFileName

гдеsRelPathэто относительный путь до файла, аsFileNameэто имя файла. Для данного примера имя класса контроллера будетControllerExtensionModuleProductmarkedfield

• status- статус вкл/выкл, по умолчанию включен

• sort_order- порядок сортировки (OpenCart 3.0), чем меньше значение, тем выше приоритет выполнения, по умолчанию 0

Отдельно стоит рассказать про отношениеtriggerиaction.triggerуказывается полным путем(почти)до файла(и в случае контроллера или модели еще и указанием выполняемого метода)вместе с контекстомadminилиcatalog, аactionуказывается относительным, безadminилиcatalog. Например,

• trigger-admin/view/catalog/product_form/after,action-extension/module/productmarkedfield/eventProductFormAfter, полный путь до файла обработчикаadmin/controller/extension/module/productmarkedfield.phpметодControllerExtensionModuleProductmarkedfield::eventProductFormAfter

• trigger-catalog/model/checkout/order/addOrderHistory/after,action-extension/module/productmarkedfield/eventaddOrderHistoryAfter, полный путь до файла обработчикаcatalog/controller/extension/module/productmarkedfield.phpметодControllerExtensionModuleProductmarkedfield::eventaddOrderHistoryAfter

Для примера работы с функциями добавления/удаления обработчиков, возьмеммодуль дополнительного поля в карточке товараиз предыдущей статьи.

Код регистрации обработчика событий для OpenCart 2.3 будет выглядеть так:

$this->load->model('extension/event'); //событие "после загрузки формы товара" - для показа дополнительного поля товара (обязательна маркировка или нет)$this->model_extension_event->addEvent(  'productmarkedfield', //название модуля  'admin/view/catalog/product_form/after', //событие   'extension/module/productmarkedfield/eventProductFormAfter' //обработчик

А для OpenCart 3.0 так:

$this->load->model('setting/event'); //событие "после загрузки формы товара" - для показа дополнительного поля товара (обязательна маркировка или нет)$this->model_setting_event->addEvent(  'productmarkedfield',  'admin/view/catalog/product_form/after',  'extension/module/productmarkedfield/eventProductFormAfter'

Если количество обязательных аргументов обработчика события превышает количество передаваемых аргументов роутером, то обработчик не будет запущен!

Количество обязательных аргументов обработчика имеет значение.system/engine/action.php Action::executeпри помощи рефлексии определяет количество необходимых аргументов и если их в обработчике больше чем может передать объектactionтогда ожидаемException:

$reflection = new ReflectionClass($class);         if ($reflection->hasMethod($this->method) && $reflection->getMethod($this->method)->getNumberOfRequiredParameters() <= count($args)) {    return call_user_func_array(array($controller, $this->method), $args);} else {    return new \Exception('Error: Could not call ' . $this->route . '/' . $this->method . '!');}

Удаление обработчиков событий

Методы удаления уже имеют значительную разницу.

В OpenCart 2.3 у моделиextension/eventметодdeleteEventудаляет все обработчики событии модуля по коду(кусок кода из OpenCart 2.3):

public function deleteEvent($code) {    $this->db->query("DELETE FROM `" . DB_PREFIX . "event` WHERE `code` = '" . $this->db->escape($code) . "'");}

OpenCart 3.0 предоставляет немного больше. МетодdeleteEventудаляет обработчик события по его идентификатору, а методdeleteEventByCodeудаляет все обработчики события по коду, какdeleteEventв OpenCart 2.3(кусок кода OpenCart 3.0):

public function deleteEvent($event_id) {    $this->db->query("DELETE FROM `" . DB_PREFIX . "event` WHERE `event_id` = '" . (int)$event_id . "'");} public function deleteEventByCode($code) {    $this->db->query("DELETE FROM `" . DB_PREFIX . "event` WHERE `code` = '" . $this->db->escape($code) . "'");}

Таким образом удаление обработчиков событий для OpenCart 2.3 будет выглядеть так:

$this->load->model('extension/event');$this->model_extension_event->deleteEvent('productmarkedfield');

А для OpenCart 3.0:

$this->load->model('setting/event');$this->model_setting_event->deleteEvent('productmarkedfield');

Итог

Система событий OpenCart достаточна интересна, она позволяет многое и гибко, но не без недостатков. Больше всего смущает тот факт, что для изменения интерфейса(события загрузки представлений)необходимо вручную работать с DOM.

Для понимания содержимого аргументов события нужно изучать исходный код загружаемых файлов, а в случае представлений также необходимо изучать контроллер, который передает в это представление данные. Однако со временем этот факт перерастает из "недостатка в достоинство" раскрывая прелесть движка OpenCart :)

Автор: Виталий Бутурлин

Источник