Alto CMS v.1.1: некторые «плюшки» для разработчиков

Это статья для разработчиков. Поэтому буду краток:
1) Возможность установки плагинов в поддиректории
2) Человекопонятный синтаксис вызов методов модулей
3) Плагин для разработчиков
Возможность установки плагинов в поддиректории
Известно, что у плагина есть «манифест» — XML-файл, где, кроме прочего, указывается директория, куда должен быть установлен плагин. До недавнего времени это работало лишь номинально, и название директории совпадало с именем плагина. Но теперь при установке плагина этот параметр реально учитывается. Вот пример (XML-файл не весь, с сокращениями):
<?xml version="1.0" encoding="UTF-8"?>
<plugin>
    <id>mine</id>
    <name>
        <lang name="default">It's my plugin</lang>
    </name>
    <author>
        <lang name="default">Ivan Petrov</lang>
    </author>
    <version>1.0</version>
    <dirname>mine</dirname>
</plugin>
Плагин будет установлен в директорию /common/plugins/mine.
<?xml version="1.0" encoding="UTF-8"?>
<plugin>
    <id>mine</id>
    <name>
        <lang name="default">It's my plugin</lang>
    </name>
    <author>
        <lang name="default">I'm programmer</lang>
    </author>
    <version>1.0</version>
    <dirname>ivanpetrov/mine</dirname>
</plugin>
Плагин будет установлен в директорию /common/plugins/ivanpetrov/mine.

Это может быть удобно для группировки плагинов, связанных между собой. Например, есть плагин для заказа пиццы, а к нему пишется несколько плагинов для разных способов оплаты и доставки, которые в принципе не работают без основного плагина. И тогда логично было бы объединить их все в одной директории.

Либо просто какой-то разработчик захочет все свои плагины в одной директории группировать по принципу vendor/pluginname. Теперь это возможно.

Человекопонятный синтаксис вызов методов модулей
Известно, что для вызова методов различных модулей используется такой синтаксис:
// Вызываем метод <strong>GetUserById()</strong> модуля <strong>ModuleUser</strong> 
// (или его наследников, если модуль мыл расширен каким-либо плагином)
$oUser = $this->User_GetUserById($iUserId)
Но меня давно свербило то, что это неверно семантически. Т.к. обращение к $this подразумевает, что мы как бы к методу класса обращаемся, внутри объекта которого делается вызов, а на самом деле мы обращаемся к внешнему объекту. Поэтому с некоторых пор такой вызов можно было оформлять в более приемлемом синтаксисе:
$oUser = E::User_GetUserById($iUserId)
Тут более наглядно видно было, что идет обращение к ядру движка. Но мне этого было мало. И вот в версии 1.1 появляется новый синтаксис:
$oUser = E::ModuleUser()->GetUserById($iUserId)
Вот, это самое то! Теперь невооруженным глазом видно (даже новичку, который только-только начал ковыряться с движком), что берется объект ModuleUser и вызывается его метод GetUserById(). Либо можно использовать такую форму:
$oUser = E::Module('User')->GetUserById($iUserId)
Не знаю, кому как, а по сравнению со старым синтаксисом — глазу загляденье!

Если же требуется явно указать модуль конкретного плагина, то это оформляется так:
$oUser = E::Module('PluginMine\User')->GetUserById($iUserId)
Это, как поймут старожилы, вместо устаревшего
$oUser = $this->PluginMine_User_GetUserById($iUserId)
И да, об «устаревшем» — старый синтаксис тоже поддерживается и в ветке 1.х будет работать и дальше. Но я б советовал разработчикам в своих плагинах использовать уже новый синтаксис. Еще и по причине, что он поддерживается плагином, о котором речь ниже.

Плагин для разработчиков
Этот плагин сильно облегчит разработку тем, что дает понять IDE, какой класс возвращается, например, при вызове E::ModuleUser() и предложит список всех методов этого класса. Подчеркну — будет возвращаться не просто класс ModuleUser, а с учетом всех наследований, которые были навешаны на него всеми активными плагинами.

Вторая фича плагина — он может вставлять в генерируемый HTML-код комментарии, которые обозначают начало и конец подключаемого шаблона. Ну очень удобно, когда страница генерируется из десятка файлов, да еще некоторые плагины норовят свои шаблоны в этом процессе задействовать, а тебе надо понять, в каком конкретно файле шаблона образовался косяк.

Плагин пока на гитхабе — https://github.com/altocms/alto-plugin-dev , т.к. в процессе допилки и доводки, но уже вполне себе рабочий.

Похожие статьи


7 комментариев

0
Ох, и обращение к модулям поменяли.

А если в модуле несколько сущностей? Вот к примеру есть плагин, у него есть модуль stat и все таблицы плагина имеют вид prefix_stat_table1, prefix_stat_table2. И к ним я мог обратиться
$oTable1 = $this->PluginMine_Stat_GetTable1ByTable1Id($Id)
На новой схеме это все будет работать?
+3
Без паники! :) Вот этот самый код, что ты привел, без всяких изменений будет работать, как и прежде. Т.е. перелопачивать старый код и его менять не требуется.

Но если писать новый плагин, то этот же вызов там может быть оформлен так:
$oTable1 = E::Module('PluginMine\Stat')->GetTable1ByTable1Id($Id);
0
Очень спасибо!

Только я не очень понял как в IDE это заводится? Никакога плагина для phpstorm не нада? Он(phpstorm) из диры с плагином альты все что нада для автодополнения узнает?

ЗЫ. Требую продолжения банкета! :) То есть побольше инфы для разработчиков. Может какой нить cookbook? Например, для меня такой(необчный) подход наследования довольно непривычен, а если были бы примеры раскрывающие всю его красоту(при создании плагинов/модулей), было б здорово. Еще раз спасибо!
0
поставил плагин, перезапустил phpstorm — нифига не подсказывает :(
еще интересно, как IDE будет реагировать на вещи типа:
E::Module('User')->…
или
E::Module('PluginMine\Stat')->…
+1
Там все банально и безхитростно — после установки плагина надо перезагрузить страницу, и будет создана папка (по умолчанию — /_dev), в которой плагин сгенерит два файла с описаниями классов в PhpDocs. IDE их подхватывает и начинает работать автокомплит.

На вещи типа E::Module('User') никак не будет реагировать, увы, тут такие простые примчики уже не прокатят, а нужно более серьезное расширение для IDE писать.

По поводу cookbook — да, давно пора, но пока ресурсов на это не хватает. Но постараюсь на днях выложить короткую презентацию, которая описывает общий принцип работы движка. А также статью про динамическое автонаследование, на котором вся система плагинов строится.
-1
Новый синтаксис на порядок улучшает читабельность кода, просто для новичка который садиться за чужой код порой сложно понять что же в $this находиться. А при новой записи тут уже не спутать не с чем, очень убодно. Спасибо за такие плюшки.

P>S. я без наезда просто приколько читать
// (или его наследников, если модуль мыл расширен каким-либо плагином) :) Модуль МЫЛ это круто.
Отредактирован:
комментарий был удален
Только зарегистрированные и авторизованные пользователи могут оставлять комментарии.