SIMAI Framework 4 (SF4) — продукт SIMAI: комплекс фронтенда и виртуальной CMS поверх Bitrix
SIMAI Framework 4 (SF4) устроен как связка двух частей, которые вместе дают «сборочную платформу» поверх 1С-Битрикс:
- Фронтенд SF4 опирается на принципы и сетку Bootstrap 4, но не сводится к нему: в SF4 добавлен собственный слой утилит/компонентов/паттернов и централизованная система ассетов (версии библиотек, пакеты, подключение). Это позволяет держать единый стиль и предсказуемое поведение интерфейса между проектами, а не «каждый раз собирать всё заново».
- Бэкенд SF4 — это набор модулей, конфигураций, мастеров и инструментов, которые превращают Bitrix в «виртуальную CMS» для ускоренной сборки решений: страница собирается из заранее описанных конфигов, блоков и представлений, а редактирование/перенос/повторное использование делается через единые механики.
Цели: ускорить сборку интерфейсов, дать адаптивную сетку, библиотеку блоков, единые настройки и мастера для развёртывания и миграций
SF4 проектировался вокруг практической цели: уменьшить стоимость “сборки страницы” и “сборки сайта” — не только на уровне верстки, но и на уровне управления структурой, настройками и переносом решений.
На практике это выражается в трёх опорных идеях:
-
Интерфейс собирается из повторно используемых «кирпичиков»: есть сетка/контейнеры, есть набор блоков, есть представления (view), которые задают композицию блоков, и есть параметры, которыми эти блоки управляются.
-
Настройки стандартизированы и наследуются: один и тот же параметр (например, поведение/видимость/оформление) можно задавать на уровне сайта, раздела, страницы и пользователя — а итоговое значение агрегируется «сборщиком» настроек.
-
Развёртывание и перенос делаются через инструменты: мастера (wizard) и действия (action) — это отдельный слой, который закрывает сценарии импорта/экспорта/инициализации и снижает долю ручной работы при миграциях и масштабировании решения.
Архитектура: ядро, шаблон, слой данных сайта, компоненты, мастера, универсальные свойства, конфиги ассетов и шрифтов
Архитектурно SF4 построен так, чтобы ядро можно было обновлять, а проектные доработки не терялись. Поэтому система разделена на «системные» и «сайтовые» области.
1) Ядро SF4 (/simai) внутри модуля /simai — системная часть: здесь живут системные блоки, ассеты, конфиги фреймворка, мастер и его действия (actions), административные интерфейсы. Логика простая: в проектах это не правят, а расширяют через слой данных.
2) Системный шаблон (/bitrix/templates/simai.framework) Это базовый шаблон, который отвечает за каркас страницы (layout), подключение ассетов, включаемые области и т. п. Кастомизация делается не правкой шаблона «внутри», а через слой {site_dir}/simai.data/template (добавления/переопределения).
3) Слой данных сайта ({site_dir}/simai.data) Это ключ к «виртуальной CMS»: здесь хранятся конфиги, структура, шаблонные override-файлы, гриды, view и block, языковые файлы и прочие ресурсы сайта. То есть всё, что должно переживать обновления ядра.
4) Bitrix-компоненты (/bitrix/components/simai) Набор компонентов покрывает типовые задачи (грид/блоки, инфоблоки, HL-блоки (Highloadblock), меню, формы, мастер и т. д.). Важный момент: компоненты здесь выступают «движком сборки» и «точками интеграции» — именно ими на странице запускается грид и связанные с ним механики.
5) Мастера (/simai/wizard/action) Модель мастера (wizard) в SF4 — это универсальный пошаговый процесс (контейнер + шаги + действия). Действия (actions) — атомарные операции (например, работа с файлами/сайтом/инфоблоками/опциями), из которых собираются сценарии импорта/экспорта/развёртывания.
6) Универсальные свойства (simai.property*) Это отдельный пласт типизации и шаблонов ввода/отображения: свойства используются как «строительный материал» для форм настроек и редакторов, чтобы не изобретать заново UI/валидации/форматы на каждом проекте.
7) Конфиги ассетов/шрифтов (ядро + сайт) Система ассетов и шрифтов разведена на уровень ядра и уровень сайта: ядро задаёт базу, а сайт через свои конфиги выбирает версии/пакеты/наборы (и добавляет своё). Это напрямую поддерживает идею «одно ядро — много проектов — управляемые различия».
Ключевые возможности: simai:sf.grid, реестр блоков, уровни настроек, публичный редактор, мастера, готовые компоненты, централизованные ассеты и шрифты
1) Конструктор страниц через simai:sf.grid Грид (grid) в SF4 — это точка сборки страницы: страница описывается через строки/колонки (12-колоночная модель и брейкпоинты в логике Bootstrap), а внутрь колонок подключаются области и блоки через выбранное представление (view).
Пример: минимальный запуск сборки страницы компонентом грида
<?php
$APPLICATION->IncludeComponent(
"simai:sf.grid",
".default",
[
"VIEW" => "home_main",
]
);
(Значение VIEW — пример; реальные доступные варианты определяются конфигурациями view и параметрами компонента.)
2) Реестр блоков: системные + переопределения на уровне сайта У SF4 есть «системные блоки» (ядро) и «блоки сайта» (override в {site_dir}/simai.data). Смысл реестра в том, что страница ссылается на блоки по коду, а проект может:
- использовать системный блок как есть;
- либо переопределить его реализацию в слое данных, не меняя ядро.
Это и есть механизм безопасной кастомизации без форков: ядро обновляется, а проектные переопределения остаются в simai.data.
3) Уровни настроек (сайт/раздел/страница/пользователь) и сборка итогового массива Система настроек построена как «матрёшка»: более частный уровень перекрывает общий. При загрузке страницы формируется итоговый набор настроек для пользователя, что позволяет персонализировать интерфейс/поведение без дублирования конфигов.
Пример: где “живут” значения на разных уровнях
Настройки фреймворка: /simai/config/.framework.config.php
Настройки сайта: {site_dir}/simai.data/.site.property.php
Настройки раздела: {ПАПКА_РАЗДЕЛА}/.property.php
Настройки страницы: {ПАПКА_РАЗДЕЛА}/.property.php
Настройки пользователя: сессия пользователя
4) Публичный редактор инфоблоков и админ-инструменты Отдельно отмечена поддержка публичного редактирования данных инфоблоков (разделы/элементы) и наличие административных сценариев редактирования/конфигурирования (включая config-страницы и iblock-сценарии). Это важно именно в контексте «виртуальной CMS»: редактирование становится частью платформы, а не разрозненным набором страниц “как получится”.
5) Мастера импорта/экспорта и сценарии развёртывания Wizard + actions — это инфраструктура, на которой строятся повторяемые операции: импорт/экспорт данных, развёртывание типовых структур, перенос элементов решения между окружениями. Для документации это особенно полезно: можно описывать «сценарии», а не отдельные ручные шаги.
6) Готовые компоненты для типовых задач В составе SF4 зафиксирован набор компонентов под практические потребности: работа с инфоблоками (списки/детальные/разделы/таблицы/фильтры/календарь), HL-таблицы, грид/блоки, формы обратной связи и обращения, меню и навигация, шаринг/виджеты, PDF-просмотр, мастер и шаги мастера и т. д. Это важная часть ценности SF4: быстро собрать решение можно только тогда, когда “типовые кирпичи” уже есть и согласованы между собой.
7) Централизованные ассеты и шрифты (управляемые версии/пакеты) Система ассетов в SF4 — это не просто “подключили CSS/JS”, а управляемая модель (версии библиотек, пакеты, выбор активной версии через настройки). На уровне сайта можно добавлять/переопределять подключение через конфиги, не ломая ядро и не размазывая подключения по шаблонам.
Где брать детали и примеры
Чтобы последующие разделы документации были «доказуемыми» и прикладными, удобнее держать в голове простую карту источников внутри проекта (не как список файлов, а как типы артефактов):
- Описание функциональных подсистем: уровни настроек, сборка итогового массива, публичный редактор и админ-сценарии — это база для разделов про конфиги/наследование/редактирование.
- Карта структуры и состава SF4: используется, когда нужно точно объяснять “что где лежит” и “что является системным, а что проектным”.
- Примеры гридов и параметров: нужны, чтобы показать читателю реальную “механику сборки страницы” (строки/колонки/контейнер/фон/условия/адаптивность) и дать 1–2 живых конфигурации.
- Реестр view/block и примеры страниц: помогают иллюстрировать, как выглядит результат и как связаны «представление → блоки → параметры».
- Обзорные материалы: полезны как “входная точка” — чтобы быстро объяснить идею SF4 до погружения в детали.