Forums / National / Russian / Тех. поддержка / Запросы документации

Принимаем вопросы от населения

Dayver
#46368 2023-04-05 01:59

Стоит отметить так же что

[BEGIN_COT_EXT]
Code=codeofplug
...
[END_COT_EXT]

в .setup.php является не обязательной строчкой и её можно опускать и код плагина будет вычислятся на базе имени папки этого самого плагина.


Что же касается:

#46362 Kabak:

1) движок сам генерит такие теги для плагинов ?

{PHP.cot_plugins_active.search}

Ну по сути это не те класические локальные теги которые подготавливаются в php и потом доступны в tpl а глобальные теги (сам я их называю ссылками на переменные). Попытаюсь подтолкнуть к полному раскрытию вопроса.

Допустим по классике еще с истоков движка всегда что б передать что то в шаблон то в php нужно было написать:

...
    $t->assign(array(
        'MY_DATA_PARAM' => $param_for_tpl
...

и потом в шаблоне tpl можно было применить так тег

<!-- BEGIN: MAIN -->
...
{MY_DATA_PARAM}
...
<!-- END: MAIN -->

А вообще читаем этот мануал про XTemplate. Но в процесе перерождения из Seditio в Cotonti и взрослении последнего шаблонизатор был переписан, и теперь это CoTemplate и два мануала по нему - один и два (я склоняюсь что этот приоритетнее). Из второго мануала видим что тегов теперь два вида - локальный (тот к которому привыкли еще с Седа) и глобальный (новое что уже появилось в переписанном шаблонизаторе).

Тоесть если упростить то любую php переменную можно как вывести в шаблон используя {PHP.paramName} так и обратится к ней в операторах IF и FOR с тем же синтаксисом. Обращение к PHP.cot_plugins_active.search это обращение к элементу массива. Опять же почитайте второй мануал. Реализован доступ из шаблона к php переменным сделан для упрощения для того что бы ради каждого чиха не приходилось делать вот эти телодвижения:

...
$t->assign(array(
'MY_DATA_PARAM' => $param_for_tpl
...

 

Что же касается конкретно cot_plugins_active то это глобальный массив который содержит список установленых плагинов (в будущем скорее всего эту роль будет выполнять только аналог - cot_plugins_enabled а cot_plugins_active будет ликвидирован). Эти массивы могут быть использованы для проверок установлености расширений в php коде. Для подобного использования в шаблонах они напрямую не очень подходят (могут вызывать предупреждения аля ошибки) и проверять установленость расширения стоит с помощью функций cot_plugin_active('plugCode') - для плагинов и cot_module_active('modCode') для модулей и уже с помощью них делать это безопасно в том числе и в шаблонах.

<!-- IF {PHP|cot_plugin_active('search')} -->
Разметка которая будет включена в вывод тоелько если плагин search установлен
<!-- ENDIF -->

Так же стоит упомянуть что в движке есть не явная особеность - перечисленные выше массивы и функции фиксируют "установленость" расширения, а не фактическое наличие самого расширения (что логично)  или его полноценной активности (что уже вызывает вопросы). Тоесть если в админке установить расширение то оно будет считатся установленным, а потом если через свойства расширения приостановить все его части (чем по факту он отключится полностью) но он не потеряет статус установленного в вышеупомянутых массивах и функциях. При необходимости определять такие тонкости в php коде можно использовать массив $cot_plugins.


#46362 Kabak:

2) нужно самому придумывать имена для таких кусков в TPL

    <!-- BEGIN: SUBSECTION -->

    <!-- END: SUBSECTION -->

есть ли какая-нибудь методика или всё на усмотрение автора плагина ?

Есть традиция но всё конечно же на усмотрение автора. 

Традиция именования такова что имена секций для системных шаблонов такие:

<!-- BEGIN: MAIN -->

    <!-- BEGIN: ROW -->
    Для циклов
    <!-- END: ROW -->

<!-- END: MAIN -->

Для плагинов и модулей иногда имя основной секции вместо MAIN используют имя расширения например 

<!-- BEGIN: MYPLUG -->

<!-- END: MYPLUG -->

Но это всего лишь традиции и если отступать от неё то ничего не сломается и будет работать успешно. Просто стоить выбирать для такого именования логичные имена дабы ваш код или разметка были легко читаемыми для вас самих и другим разработчиками - это уже уже чисто правило хорошего тона внутри профессии.

Pavlo Tkachenko aka Dayver
This post was edited by Dayver (2023-04-05 02:11, 1 year ago)