Расширение стандартного функционала

В процессе взаимодействии пользователя с системой может возникнуть ситуация, когда нужно расширить возможности стандартных модулей системы: дополнить их функционал собственными методами, а также предоставить для удобной работы с ними собственный административный интерфейс. Наряду с возможностью кастомизации функционала системы в версии UMI.CMS 2.9.7 появилась возможность создавать для существующих модулей собственные расширения с уникальными именами, обеспечивая их полное разделение в пределах одного модуля.

Новая система расширения стандартного функционала позволяет легко добавлять в систему собственные, а также сторонние расширения без пересечения их кода и без угрозы его потери при обновлении. Особенно актуальна эта возможность при публикации собственных расширений в UMI.Market.

Расширение функционала существующих модулей

Новая система подразумевает размещение пользовательского расширения в специальных директориях “ext”, в файлах, имена которых исключают пересечение кода внутри модуля. Любое уникальное расширение может быть расположено в директории classes/components/{модуль}/ext (где модуль - директория расширяемого модуля) и может состоять из следующих файлов:

admin_{расширение}.php

site_{расширение}.php

common_{расширение}.php

includes_{расширение}.php

__events_{расширение}.php

events_{расширение}.php

permissions.{расширение}.php

i18n.{расширение}.{локаль}.php

lang.{расширение}.{локаль}.php

Где расширение - уникальное имя расширения, а локаль - языковая версия файлов языковых констант (может быть ru или en). Обратите внимание для этих файлов необходимо явно указать языковую версию, локаль по умолчанию не поддерживается. Структура файлов c именами вида events_{расширение}.php (назначение обработчиков событий), permissions.{расширение}.php (управление правами), i18n.{расширение}.{локаль}.php и lang.{расширение}.{локаль}.php (локализация) довольна проста и аналогична таковым при создании модуля.

Стоит отметить что данная система расширения может быть использована для локализации языковых констант в существующих модулях. К примеру модулю или расширению может потребоваться локализовать тип данных (модуль Шаблоны данных, системное название data). Реализовать это можно созданием директории ext в модуле data и файла языковых констант для модуля или расширения, которому требуется перевод типа данных, по вышеуказанному шаблону.

Файлы admin_{расширение}.php, site_{расширение}.php, common_{расширение}.php, includes_{расширение}.php и __events_{расширение}.php требуют особого внимания. Рассмотрим особенности структуры этих файлов на примере расширения myextension.

Файл, содержащий методы административного интерфейса, будет иметь имя admin_myextension.php и содержать следующий код:

<?php
    class admin_myextension {

        public function __construct($module) {
            $this->module = $module;

            $commonTabs = $this->module->getCommonTabs();

            if ($commonTabs) {
                $commonTabs->add('myextension');
            }
        }

        public function myextension() {
        //...
        }
    }
?>

Поместив метод __construct() в код класса вашего расширения можно выполнить какую-либо логику на этапе инициализации расширяемого модуля. Данный пример расширения добавляет в административный интерфейс существующего модуля вкладку с системным именем myextension. Далее идёт одноимённый метод myextension(), метод по умолчанию для вкладки вашего расширения в административном интерфейсе. Класс административной части вашего расширения может содержать и другие методы, и ограничением тут является только уникальность имён вашего расширения и расширяемого модуля.

Файл, содержащий методы сайтовой части вашего расширения, будет называться site_myextension.php и его код будет иметь более простую структуру:

<?php
    class site_myextension {
        public function mymethod() {
            //...
        }
    }
?>

Метод mymethod() приведён для примера, количество и уникальность имён методов, расширяющих сайтовую часть существующего модуля может быть любым и ограничено, как и в случае с административной частью, только уникальностью имён и их функциональной необходимостью.

Методы, являющиеся общими для административной и сайтовой части системы, следует поместить в файл common_myextension.php. Он может иметь следующее содержание:

<?php
    class common_myextension {
        public function myAdminMethod() {
            //...
        }
        public function mySiteMethod() {
            //...
        }
    }
?>

Имена и количество методов соответствует правилам, аналогичным правилам для файлов admin_myextension.php и site_myextension.php.

Пользовательские функции, конструкции подключения сторонних библиотек (include, require и т.д.) следует поместить в файл includes_myextension.php.

Обработчики событий клиентской части для расширяемого модуля должны находиться в файле __events_myextension.php

(обработчики событий административной части должны находиться в файле admin_myextension.php). Содержимое файла может иметь следующую структуру:

<?php
    class __events_myextension {
        public function myEventHandler() {
            //...
        }
    }
?>

Как и в случае admin_myextension.php и site_myextension.php, количество методов (здесь методов - обработчиков событий) ограничено только уникальностью имён расширяемого модуля и необходимостью.

Расширение шаблонов существующих модулей

Шаблоны, расширяющие административный интерфейс существующих модулей, должны располагаться в директории вида styles/skins/modern/data/modules/{модуль}/ext. Т.е. аналогично директории ext в каталоге расширяемого модуля, шаблоны вашего решения располагаются в директории ext в каталоге шаблонов модуля. Файлы шаблонов должны названы следующим образом:

{mode}.{ext_name}.xsl

Здесь mode - тип шаблона по назначению, а ext_name - имя расширения, что, согласно примеру из секции Расширение функционала существующих модулей, соответствует значению myextension. Остановимся подробнее на типах шаблонов, они представляют из себя часть названия базовых шаблонов модулей и отражают своё функциональное назначение:

form.modify

list.modify

list.view

settings.modify

settings.view

Таким образом, например, шаблон административного интерфейса вашего решения myextention для отображения формы добавления и редактирования объекта будет иметь имя form.modify.myextension.xsl, а шаблон, отображающий табличный интерфейс списка объектов - list.view.myextension.xsl.

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

Была ли данная статья полезна?