home chevron_right
Экосистема модулей SF4

Обязательные: simai.framework (ядро, компоненты, ассеты, мастера), simai.property (универсальные свойства), при необходимости simai.property4field, simai.property4iblock (доп. типы свойств)link

Базовая конфигурация SF4 строится вокруг модуля simai.framework: он содержит основную библиотеку классов, инфраструктуру мастеров, и системные механики (например, загрузку ассетов из системного реестра). В рамках этой же архитектуры отдельным “столпом” идут универсальные свойства: модуль simai.property и расширения simai.property4field, simai.property4iblock (когда нужны интеграции свойств с пользовательскими полями и инфоблоками).

На уровне практики это выглядит так:

  • simai.framework отвечает за “каркас” (как SF4 живёт в Bitrix, как подключается шаблон/области, как работают мастера и т.д.).
  • семейство simai.property* отвечает за “типизацию” настроек/полей и шаблоны их отображения (то, что делает формы настроек и формы редактирования предсказуемыми и расширяемыми).

Сервисные/опциональные: backup/filebackup (резервное копирование), iblockcopy (копирование инфоблоков/структур), bxeditor (визуальный редактор), simai.update (механизм обновлений), прочие вспомогательные модули по структуре проектаlink

В поставке SF4 зафиксированы сервисные модули:

  • simai.backup (резервное копирование),
  • simai.iblockcopy (операции переноса/копирования по инфоблокам),
  • simai.bxeditor (расширения вокруг визуального редактора),
  • simai.update (инфраструктура обновлений).

Модуль filebackup как отдельная единица не найден в локальных данных (если в ваших проектах он существует под другим именем — понадобится уточнение по точному коду модуля).

Роли: ядро отвечает за структуру, компоненты, ассеты и мастера; property-модули дают типы/шаблоны свойств; сервисные обеспечивают перенос/копии/обновления/редакторыlink

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

simai.framework Даёт библиотеку классов и базовые подсистемы. В библиотеке ядра выделяются “пакеты” по смыслу:

  • SIMAI\Main\Configuration\* — чтение/запись настроек сайта/разделов/страниц и хранение итоговых свойств (в том числе session-store);
  • SIMAI\Main\Page\* — работа с ассетами/шрифтами/мета;
  • SIMAI\Main\IO\* — include-области, шаблонные области;
  • SIMAI\Main\Block\* — блоки и режимы редактирования;
  • SIMAI\Wizard\* — утилиты, которые используются мастерами.

simai.property* Даёт систему универсальных свойств (типы/шаблоны/интеграции), на которой строятся типизированные формы.

Сервисные (simai.backup, simai.iblockcopy, simai.bxeditor, simai.update) Закрывают “инфраструктурные” задачи: сопровождение, переносы, редакторы, обновления.

Зависимости и риски: без simai.property* ломаются настройки и публичный редактор (нет типов/шаблонов); без simai.framework не работают компоненты/грид/мастер; без сервисных модулей недоступны копии/бэкапы/редактор, тормозят миграцииlink

Если говорить прикладно, по тому как SF4 устроен:

  • Без simai.framework перестаёт существовать сам “каркас” SF4: библиотека классов, мастера, базовые компоненты и системные механики.
  • Без simai.property и расширений simai.property* сильно проседают сценарии, где нужны типы/шаблоны свойств (в частности — любые формы настроек/редакторов, которые завязаны на универсальные свойства). То есть риск — не “всё падает”, а именно теряется типизированная часть форм и конфигов.
  • Без сервисных модулей ядро SF4 продолжает работать, но становятся недоступны соответствующие сервисные сценарии (бэкапы, удобные переносы, расширения редактора, инфраструктура обновлений), и сопровождение проекта становится более ручным.

Важное уточнение из вашей практики (чтобы не закреплять неверный путь в документации): проектный файл {site_dir}/simai.data/config/.asset.config.php у вас не используется — поэтому любые рекомендации “переопределять ассеты через simai.data/config” для ваших проектов неверны. В вашей схеме проектные подключения делаются через слой шаблона {site_dir}/simai.data/template/..., а системный реестр ассетов живёт в системном слое SF4.

Шаблон описания сервисного модуля: назначение; зависимости; что создаёт (таблицы/настройки); какие страницы/мастера/команды добавляет; как безопасно отключать/удалятьlink

Для документации SF4 удобно описывать сервисные модули единым “паспортом”, чтобы читатель быстро понимал последствия установки/отключения:

  1. Назначение — какую задачу решает модуль (1–2 предложения).
  2. Зависимости — от каких модулей SF4/Bitrix зависит и какие сценарии SF4 его используют.
  3. Артефакты — что модуль добавляет в систему (таблицы, опции, агенты/крон, файловые структуры).
  4. Интерфейсы — какие админ-страницы, мастера, команды или компоненты появляются после установки.
  5. Безопасное отключение/удаление — что нужно проверить перед удалением (используется ли функциональность, есть ли данные, нужны ли бэкапы), и что “пропадёт” после удаления.