Фокус глубины: типы/шаблоны свойств, применение в настройках и блоках, пример подключения нового шаблона через модуль свойств без правок ядраlink

В SF4 «универсальные свойства» — это общий механизм, который позволяет описывать параметры (настройки, поля, опции блоков) один раз в виде декларации типа данных и (при необходимости) UI-шаблона, а дальше использовать это описание в разных интерфейсах: в настройках сайта/разделов/страниц, в настройках блоков/гридов, в админских инструментах и в мастере.

Практически это выглядит так:

Тип (type) определяет модель данных и базовую логику: строка, число, дата/время, список, файл, цвет и т.д.
Шаблон (template) определяет как именно это поле выглядит в UI: обычный список, список с превью картинок, переключатель, радио-кнопки и т.п. (часто шаблоны начинаются с sf4.*).

Ключевой момент для разработки решений: вы не «рисуете форму руками», а задаёте конфигурацию, и SF4 отрисует правильный контрол, сохранит значение и применит его дальше по цепочке (например, как выбор активного grid_view_*, либо как параметр для area-шаблона/блока).

Ниже — минимальный пример декларации настройки выбора представления области (список с изображениями), который соответствует вашей фактической модели:

'grid_view_header' => [
    'name' => Loc::getMessage("GRID_VIEW_HEADER"),
    'type' => 'list',
    'values' => \SIMAI\Main\Block\Section::getImageList(SF_DATA_DIR . "/grid/view/header"),
    'default' => 'default',
    'template' => 'sf4.image.list',
],

Назначение: UI-абстракция типов данныхlink

Универсальные свойства предоставляют единый способ описывать поля/параметры для интерфейсов (формы, настройки, публичный редактор), абстрагируя типы данныхlink

В основе лежит единый движок, который умеет рендерить одно и то же «свойство» в разных режимах:

edit — режим редактирования (форма ввода),
view — режим просмотра (вывод значения),
filter — режим фильтра (если применимо).

Технически это реализовано через структуру «тип → шаблон → режим», где движок выбирает файл шаблона по тройке:

type (например, list, string, checkbox),
template (например, .default, sf4, sf4.switch, sf4.image.list),
mode (edit|view|filter).

Базовое размещение типов и шаблонов устроено так:

общие (системные) шаблоны типов: /simai/property/<type>/...
проектные переопределения: {site_dir}/simai.data/property/<type>/...

Важно: выбор устроен как приоритет проекта. Если для типа существует папка в {site_dir}/simai.data/property/<type>, движок будет работать с ней как с источником истины для этого типа.

Практическое следствие для команды разработки: если вы хотите «чуть подправить» UI-шаблон типа, обычно безопаснее скопировать тип целиком в {site_dir}/simai.data/property/<type> и править уже там (иначе можно неожиданно потерять шаблоны/режимы, которые где-то используются по умолчанию).

Используются в компонентах, настройках (site/section/page), публичном редакторе инфоблоков и мастере; позволяют работать по кодам, а не по IDlink

В SF4 универсальные свойства — это клей между «конфигом» и «интерфейсом»:

Настройки сайта Схема того, какие настройки доступны и как их показывать, задаётся конфигом уровня сайта ({site_dir}/simai.data/config/.site.config.php). Сами значения настроек сайта хранятся в {site_dir}/simai.data/.site.property.php.
Настройки раздела и страницы Схема доступных настроек задаётся {site_dir}/simai.data/config/.structure.config.php и может расширяться/замещаться для конкретного раздела через файл .structure.config.php в папке раздела. Значения хранятся в .property.php соответствующего раздела (например, /ru/.property.php) и включают одновременно:
- section (настройки раздела),
- page (настройки конкретных страниц внутри раздела).
Грид и представления областей (view) Редактор грида сохраняет конфигурацию в файл {site_dir}/simai.data/grid/view/.../template.php. А то, какое именно представление выбрано для области (grid_view_header, grid_view_footer, grid_view_main_top и т.д.), хранится в .site.property.php или .property.php — то есть через тот же слой настроек и универсальные свойства.
Инструменты для инфоблоков и полей Дополнительные модули расширяют «универсальные свойства» под Bitrix-сущности:
- модуль для пользовательских полей (UserField-типы),
- модуль для свойств инфоблоков (IBlock property user types).
Например, в коде присутствуют пользовательские типы вроде simai_ib_element (связь с элементом ИБ) и simai_ib_section (связь с разделом ИБ), а также набор типов для пользовательских полей (в т.ч. сценарии выбора задач и т.п.). Это и есть практическая часть тезиса «работать по кодам, а не по ID»: SF4 старается протаскивать код/человекочитаемый идентификатор как первичный ключ в настройках и UI.

Источники: описание функционала, структура свойств и шаблонов, где смотреть реализацию в проектеlink

Чтобы уверенно документировать и расширять универсальные свойства, полезно держать в голове три «слоя» реализации:

Движок и базовые типы/шаблоны Модуль simai.property устанавливает набор типов (string, number, datetime, list, checkbox, file, color, entity, map, и др.) и несколько UI-шаблонов для каждого типа (например, для list есть варианты .default, sf4.radio, sf4.button, sf4.image.list, sf4.image.card).
Точка расширения проекта Проектная версия типов/шаблонов располагается в:
- {site_dir}/simai.data/property/<type>/templates/<template>/...
Минимальный каркас одного шаблона обычно такой:

{site_dir}/simai.data/property/list/templates/my.template/
  edit.php
  view.php
  filter.php        (если нужен)
  lang/ru/edit.php  (если нужна локализация)

Использование в интерфейсах SF4 Компонент «Редактор свойств» (в SF4) рендерит поля, вызывая движок универсальных свойств. Внутри шаблона компонента используется вызов вида:

\SIMAI\Property::edit(
    $property["type"],
    $property["template"] ?: $defaultTemplate,
    $propertyValue,
    $propertyParam
);

Отсюда удобное правило: если у вас «что-то не так отображается» в настройках, проблема почти всегда находится в одном из трёх мест:

неверно описан type/template в конфиге,
для выбранного type/template нет нужного edit.php (или проект случайно «перекрыл» тип неполной копией),
не подключены нужные ассеты UI-шаблона.

Типы свойств и шаблоны отображения (в т.ч. sf4_)link

Типы: строка/число/дата/список/файл/привязка и др.link

В SIMAI Framework 4 (SF4) «универсальные свойства» — это слой, который приводит разные источники настроек и данных к единой модели полей: тип данных (что хранится) + шаблон отображения (как это выглядит в интерфейсе). Базовые типы покрывают типичные кейсы настроек и форм: строка, текст, число, дата/время, список, чекбокс, файл, карта, ссылка, шаблон URL и т.д.

В поставке модулей SIMAI Property (и расширений для Bitrix) фактически встречаются такие группы:

Базовые типы универсальных свойств (используются в настройках сайта/раздела/страницы, формах и редакторах):
- string (Строка), text (Текст), number (Число), datetime (Дата/время)
- list (Список), checkbox (Одиночный чекбокс)
- file (Файл), include (Файл как включаемый/исполняемый ресурс — полезно для «подключить/подменить файл» в настройках)
- link (Ссылка), url (Шаблон URL)
- map (Карта), phone (Телефон), color (Выбор цвета)
- entity (Привязка к сущности — обобщённый тип для выбора связанной сущности)
- sort (Сортируемый список), complex (Составное свойство хранилищ — продвинутый сценарий)
Дополнительные типы для пользовательских полей (UF_*) — когда нужно удобное поле в HL-блоке/пользовательских сущностях Bitrix (подбор элементов/разделов/пользователей и т.п.). Среди реально используемых user-type’ов есть привязки к элементам/разделам (в том числе по коду, а не по ID), поле HTML, чек-лист, выбор пользователя/задачи и карта (точечные координаты).
Дополнительные типы для свойств инфоблоков — когда требуется особое поведение именно у свойства элемента инфоблока: «ссылка», «пароль» (с действиями при показе), «стадия» (с цветами), «теги», привязки к пользователю/задаче/тикету, оптимизированное изображение и т.п.

Ключевая идея SF4 здесь та же, что и во всём фреймворке: в настройках и связях по возможности опираться на коды, чтобы конфигурации переносились между средами предсказуемо и не ломались из-за разных ID.

Шаблоны отображения (в т.ч. семейство `sf4.*`)link

Шаблон отображения отвечает за то, как одно и то же значение выглядит в UI: например, «список» можно показывать как обычный <select>, как радио-кнопки, как набор кнопок или как выбор по картинкам/превью.

В SF4 шаблоны организованы по простой файловой модели:

Системные шаблоны: /simai/property/<type>/templates/<template>/...
Проектные переопределения (если нужно поправить UI под конкретный сайт): {site_dir}/simai.data/property/<type>/templates/<template>/...

То есть правило ровно такое же, как и для остального SF4: системное лежит в /simai, проектное — в simai.data.

По факту встречаются два «семейства» шаблонов:

.default — базовый (нейтральный) рендер.
sf4 и sf4.* — рендер в стиле SF4 (с компонентами/паттернами интерфейса фреймворка).

Практически важные варианты (то, что реально даёт разницу в UX):

Для list (Список), помимо .default и sf4, есть специализированные:
- sf4.button (как кнопки),
- sf4.radio (как радиогруппа),
- sf4.image.list (выбор из списка с превью),
- sf4.image.card (выбор карточками/превью).
Для checkbox (Булево), помимо .default и sf4, встречаются:
- sf4.switch (переключатель),
- sf4.image (визуальный вариант с изображением/иконографикой).
Для include (Файл как включаемый ресурс), помимо .default и sf4, есть варианты для более удобной правки содержимого:
- sf4.editor,
- sf4.script.

Важно: в плане у вас встречалось написание sf4_…, но в реальных идентификаторах шаблонов используется формат sf4 / sf4.* (с точкой), например sf4.image.list.

Использование: настройки сайта/раздела/страницы, публичный редактор, мастераlink

Тип + шаблон применяются в SF4 везде, где нужно получить единообразное поле настройки:

Настройки сайта / раздела / страницы: вы описываете поле (тип, значения, дефолт, шаблон отображения), а потом это поле появляется в панели/редакторе настроек.
Публичные редакторы и админ-инструменты: те же типы и шаблоны позволяют показывать «понятные» формы без того, чтобы каждый раз писать новый UI руками.
Мастер установки/обновления: шаги мастера могут запрашивать у пользователя значения, и эти значения удобно описывать той же моделью (поле → тип → UI-шаблон), а дальше складывать в общий массив конфигурации и переиспользовать между действиями.

Характерный пример из вашего проекта — выбор представления области (header/footer/и т.д.). С технической точки зрения это обычное поле типа list, но показывается оно не «списком строк», а визуально — через sf4.image.list:

'grid_view_header' => [
    'name' => Loc::getMessage('GRID_VIEW_HEADER'),
    'type' => 'list',
    'values' => \SIMAI\Main\Block\Section::getImageList(SF_DATA_DIR . '/grid/view/header'),
    'default' => 'default',
    'template' => 'sf4.image.list',
],

Смысл такого подхода: пользователь выбирает конфигурацию (по сути — «сохранённое представление»), а UI выбора сразу ориентирует по превью и снижает ошибки при настройке.

Примеры UI и “как это выглядит” на практикеlink

Чтобы при чтении документации у разработчика сложилось правильное ожидание, полезно держать в голове простую привязку «тип → ощущение в интерфейсе»:

string, number, datetime — компактные поля, которые чаще всего используются в настройках страниц/областей (заголовок, модификатор, цвет, отступы, лимиты, даты).
list + sf4.image.list / sf4.image.card — ключ к «визуальным настройкам», где выбор лучше делать не по коду, а по превью (макеты, представления, варианты оформления).
checkbox + sf4.switch — лучший UX для «включить/выключить» (показывать заголовок, включить контейнер, скрыть сайдбар и т.д.).
include + sf4.editor / sf4.script — удобно, когда настройка фактически сводится к правке текста/фрагмента кода (и важно делать это в проектном слое, не трогая ядро).

Если в проекте вы вводите новый параметр, хорошее правило: сначала выбрать тип по данным, а затем — шаблон по UX (как это должен видеть редактор/администратор).

Дополнительные ориентиры по типам и шаблонамlink

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

Берёте системный шаблон нужного типа из /simai/property/... как «эталон».
Копируете в {site_dir}/simai.data/property/... и правите там.
В конфигурации поля указываете нужный template (например, sf4.image.list) и проверяете, что UI рендерится ожидаемо.

API получения/записи; интеграция с настройками и блокамиlink

API: хелперы/классы для работы со свойствами в модуле `simai.property` (D7 API)link

В SF4 низкоуровневый “рендеринг” универсальных свойств (то есть превращение type + template + values + params в HTML для просмотра/редактирования/фильтра) вынесен в модуль simai.property. Центральная точка входа — статический фасад \SIMAI\Property, который работает по одному принципу во всех режимах: сначала выбирает реализацию типа, затем подключает шаблон выбранного типа, передавая ему значения и параметры.

Ключевые методы у фасада:

\SIMAI\Property::view($type, $template, $values = [], $params = [], $safe = true)
\SIMAI\Property::edit($type, $template, $values = [], $params = [], $safe = true)
\SIMAI\Property::filter($type, $template, $values = [], $params = [], $safe = true)
\SIMAI\Property::types_list() — список доступных типов (с “человеческим” названием и сортировкой из описания типа)

При выборе типа и шаблона есть встроенная валидация имён (это важно для безопасности, потому что дальше идут include файлов типа/шаблона):

type допускает только a-z0-9_
template допускает a-z0-9_- . (и значение .default как шаблон по умолчанию)
mode жёстко ограничен: view | edit | filter

Разрешение файлов устроено так:

сначала ищется тип в каталоге проекта: {site_dir}/simai.data/property/<type>/
если там нет — берётся общий каталог: /simai/property/<type>/
файл логики типа: <mode>.php
файл шаблона: templates/<template>/<mode>.php
для шаблона дополнительно может подтягиваться языковой файл (если он предусмотрен структурой типа)

Параметр $safe по умолчанию включён: значения и параметры перед подключением шаблона приводятся к “безопасному” виду (для скаляров — через экранирование, для массивов — рекурсивно). Внутри SF4 это используется как “страховка” от XSS, когда значения приходят из формы или из внешних источников.

Отдельно в simai.property есть класс \SIMAI\PropertyEntitiesType. Это не “рендер”, а утилита для работы с сущностями (например, элементы/секции инфоблоков или сущности хранилища) и их полями: класс умеет по выбранной сущности вернуть описание полей, параметры фильтрации/отображения и подготовить списки, которые затем удобно использовать в админ-инструментах и редакторах.

Получение/запись: примеры использования свойств в настройках (site/section/page) и публичном редактореlink

На уровне SF4 поверх “рендера” существует слой хранения настроек, который оперирует простыми “ключ → значение” и сохраняет их в PHP-файлах с return [ ... ];. Этот слой представлен классами пространства имён SIMAI\Main\Configuration и обычно используется одинаково в админ-скриптах и в редакторах.

Базовая раскладка хранения:

настройки сайта — файл {site_dir}/simai.data/.site.property.php доступ через SIMAI\Main\Configuration\Site::getValue()/setValue() (и родственные методы для массива)
настройки секции/страницы — файл /.property.php внутри соответствующей директории доступ через SIMAI\Main\Configuration\Section и SIMAI\Main\Configuration\Page

Для секций предусмотрено “наследование” по пути: метод Section::getRecursionArray($dirProperty) последовательно проходит директории и мерджит найденные массивы настроек, формируя итоговую конфигурацию “от корня к текущей секции”. Это удобно, когда часть параметров задаётся на верхнем уровне, а дочерние разделы переопределяют только отдельные ключи.

“Публичный редактор” в SF4 в практическом смысле — это компонент, который получает:

CONFIG (описание групп и полей),
VALUES (текущие значения), и для каждого поля вызывает \SIMAI\Property::edit(...), чтобы отрисовать правильный тип ввода.

То есть логика обычно такая: SF4 хранит значения через Configuration\*, а отображает/редактирует их через simai.property.

Пример: чтение/запись настроек site/section/page

<?php

declare(strict_types=1);

use SIMAI\Main\Configuration\Site;
use SIMAI\Main\Configuration\Section;
use SIMAI\Main\Configuration\Page;

// 1) Site-level (хранится в {site_dir}/simai.data/.site.property.php)
$siteId = '/'; // в реальных сценариях это путь сайта (например, SF_SITE_DIR)
$isExpertMode = Site::getValue($siteId, 'expert_mode');
Site::setValue($siteId, 'expert_mode', 'Y');

// 2) Section-level (хранится в <dir>/.property.php)
$sectionDir = '/catalog/';
$sectionTitle = Section::getValue($sectionDir, 'title');
Section::setValue($sectionDir, 'title', 'Каталог');

// Наследование настроек секции по пути
$effectiveSectionConfig = Section::getRecursionArray($sectionDir);

// 3) Page-level (также <dir>/.property.php, но смысл — “настройки конкретной страницы/директории”)
$pageDir = '/catalog/item-1/';
$isShowTitle = Page::getValue($pageDir, 'show_title');
Page::setValue($pageDir, 'show_title', 'N');

Интеграция с блоками: параметры блоков могут использовать универсальные свойства как типы вводаlink

В SF4 блоки (и их “параметры”) могут использовать универсальные свойства как стандартный механизм ввода. Практически это выглядит так: когда блок строит форму параметров (или форму полей), он формирует $type, $value, $params и вызывает \SIMAI\Property::edit(...).

В шаблонах блоков встречается сценарий, когда “поле блока” привязывается к свойству/полю сущности. Например, значение вида PROP[CODE] используется как ссылка на свойство инфоблока: по коду выбирается описание свойства, по нему определяется тип формы (TYPE_FORM), обязательность (REQUIRED) и дополнительные параметры рендера. Если же привязки нет, блок может работать с “обычным полем” (field) и отображать его по тем же правилам.

Такой подход даёт два эффекта:

единый набор UI-шаблонов для разных типов полей (строка, телефон, текст, списки и т.д.);
единая логика обработки “одиночных/множественных” значений, required-проверок и прочих параметров ввода.

Пример: как блок рендерит поле через универсальное свойство

<?php

declare(strict_types=1);

use Bitrix\Main\Loader;

Loader::includeSharewareModule('simai.property');

$type = 'phone';      // тип ввода (может приходить из метаданных поля/свойства)
$template = 'sf4';    // шаблон рендера типа
$value = '+7 (999) 123-45-67';

$params = [
    'field_name' => 'FIELD[PHONE]',
    'required' => 'Y',
    'multiple' => 'N',
];

\SIMAI\Property::edit(
    $type,
    $template,
    $value,
    $params
);

Интеграция с мастером/настройками: свойства применяются для форм мастера и конфиговlink

В мастере (wizard) свойства участвуют как минимум в двух местах:

как механизм хранения промежуточного состояния/результатов Для этого используется SIMAI\Main\Configuration\Property: он работает как хранилище “массивом в сессии”, где ключом выступает идентификатор мастера (code), а значением — текущий arResult (или его часть). Это даёт мастеру возможность идти по шагам, собирать ввод пользователя и передавать его между действиями, не записывая данные в файлы на каждом шаге.
как источник данных для генерации/обновления конфигов Когда мастер накапливает нужные значения, дальше эти значения уже могут быть записаны в файловые конфиги уровня site/section/page через классы SIMAI\Main\Configuration\Site/Section/Page (либо использованы при подготовке структуры, данных и т.п.). Важно, что на этом этапе формат данных остаётся таким же: обычные массивы и скаляры, которые затем сохраняются в виде PHP-файлов с return.

Пример: сохранение результатов шага мастера в “Property storage” (сессия)

<?php

declare(strict_types=1);

use SIMAI\Main\Configuration\Property;

$wizardCode = 'my_wizard';
$wizardResult = [
    'STAGE' => [
        'STATUS' => 'WORK',
    ],
    'ACTION' => [
        'DATA' => [
            'site_title' => 'Demo',
        ],
    ],
];

// Сохранить состояние мастера
Property::setArray($wizardCode, $wizardResult);

// Достать состояние мастера
$stored = Property::getArray($wizardCode);

Расширение: новые типы/шаблоныlink

Добавление нового типа/шаблона свойства — через расширение модулей `simai.property*`link

В SF4 универсальные свойства расширяются не через “реестр” или регистрацию в коде, а через файловую структуру типа. Тип — это каталог с предсказуемыми файлами режимов (view/edit/filter) и набором шаблонов в templates/<template>/…. При рендере SF4 (через \SIMAI\Property::view/edit/filter) сначала выбирается каталог типа, затем файл режима типа, затем файл режима шаблона.

Базовые правила, которые важно учитывать при создании нового типа:

имя типа: только a-z0-9_ (например phone, entity, my_type)
имя шаблона: a-z0-9_- . (например sf4, sf4.switch, .default)
режимы: строго view, edit, filter
если шаблон не найден — система автоматически откатится на .default (если и его нет — рендер завершится ошибкой)

Минимальный “скелет” нового типа в проектном слое выглядит так:

{site_dir}/simai.data/property/my_type/
    .description.php
    lang/ru/.description.php

    view.php
    edit.php
    filter.php

    templates/.default/
        view.php
        edit.php
        filter.php
        lang/ru/view.php
        lang/ru/edit.php
        lang/ru/filter.php

    templates/sf4/
        view.php
        edit.php
        filter.php
        lang/ru/view.php
        lang/ru/edit.php
        lang/ru/filter.php

.description.php нужен, чтобы тип корректно “описывался” (название/сортировка) в сервисных интерфейсах/тестовых страницах модуля. Минимальный пример:

<?php

declare(strict_types=1);

if (!defined('B_PROLOG_INCLUDED') || B_PROLOG_INCLUDED !== true) {
    die();
}

$arDescription = [
    'NAME' => GetMessage('SF_PROPERTY_TYPE_NAME'),
    'SORT' => 1000,
];

А текст для GetMessage() размещается в lang/<LANG>/…:

<?php

declare(strict_types=1);

$MESS['SF_PROPERTY_TYPE_NAME'] = 'Мой новый тип';

Сами файлы режима типа (view.php, edit.php, filter.php) подключаются до файла шаблона и могут подготовить данные для шаблона или остановить рендер, установив переменную ошибки режима:

для view: $view_error
для edit: $edit_error
для filter: $filter_error

Правило: не менять системные файлы `/simai`; добавлять новые шаблоны/типы по аналогии в слое проектаlink

Системный слой /simai/property — это общий набор типов/шаблонов, который устанавливается модулем simai.property и может обновляться. Поэтому практическое правило простое: не править файлы в /simai, чтобы изменения не терялись при обновлениях и не создавали конфликты.

Для расширений предусмотрен проектный слой:

{site_dir}/simai.data/property — приоритетный слой проекта (добавления/переопределения)

При выборе типа система действует по принципу “сначала проект, потом система”:

ищет каталог типа в {site_dir}/simai.data/property/<type>
если его нет — берёт /simai/property/<type>

Из этого следует важное следствие для переопределений:

если вы создаёте каталог типа в simai.data/property/<type>, то дальше для этого типа будут использоваться файлы режимов и шаблоны именно из проектного каталога (то есть вы фактически берёте ответственность за полный комплект view/edit/filter и нужных шаблонов внутри этого типа)

Поэтому самый безопасный путь расширения обычно такой:

новый тип → отдельный каталог в simai.data/property/<new_type>/…
новый шаблон для существующего типа → добавляется через проектный слой аккуратно, с учётом того, что наличие simai.data/property/<type>/ переключит тип на проектную реализацию целиком (это место часто требует дисциплины в структуре и поставке).

Точки подключения/регистрации — ориентироваться на узлы настроек/конфигов и на существующие реализацииlink

Для свойств “точка подключения” — это фактически вызов рендера с нужными параметрами (type, template, values, params). Никакой отдельной регистрации в SF4 не требуется: достаточно, чтобы на файловой системе существовали:

файл режима типа: {site_dir}/simai.data/property/<type>/<mode>.php или /simai/property/<type>/<mode>.php
файл режима шаблона: …/templates/<template>/<mode>.php (при отсутствии — будет попытка использовать templates/.default/<mode>.php)
опционально — языковой файл шаблона: …/templates/<template>/lang/<LANGUAGE_ID>/<mode>.php

Минимальный пример использования нового типа в коде (например, в редакторе настроек или в форме блока) выглядит так: вы просто вызываете нужный режим и указываете имя шаблона, который вы положили в templates/<template>/….

<?php

declare(strict_types=1);

use Bitrix\Main\Loader;

Loader::includeSharewareModule('simai.property');

$type = 'my_type';
$template = 'sf4';
$value = 'example';

$params = [
    'field_name' => 'SETTINGS[MY_FIELD]',
    'required' => 'Y',
];

\SIMAI\Property::edit($type, $template, $value, $params);

Отдельная деталь, которая иногда важна при разработке шаблонов: в режиме edit модуль автоматически подключает общий JS-скрипт simai.property (это рассчитано на типовые интерактивные элементы ввода). Если вашему шаблону нужны дополнительные ассеты, их обычно подключают внутри шаблона через стандартный механизм Bitrix (Asset::getInstance()->addJs/addCss) — но только по факту необходимости.