Запрос → выбор активного шаблона → подключение ассетов → чтение настроек по уровням → сборка грида → загрузка view областей → рендер блоков/компонентов → кэширование/вывод
Запрос в Bitrix сначала приводит к выбору активного шаблона сайта (обычно simai.framework или шаблон решения на базе SF4). Дальше системный шаблон подключает платформенный слой SF4 и проектный слой сайта (то, что лежит в {site_dir}/simai.data/template), чтобы у страницы появились все нужные CSS/JS, общие include-части и точки расширения.
После этого SF4 собирает страницу через грид: компонент simai:sf.grid рендерит структуру, но ключевой момент у вас такой: области страницы (header/footer/home/sidebar/main top/bottom) собираются через VIEW, а VIEW — это сохранённая конфигурация, которая загружается по коду из настроек. То есть “view” — это не абстрактное понятие, а конкретная папка в simai.data/grid/view, внутри которой лежит template.php с сохранённым вызовом simai:sf.grid и параметрами строк/колонок/областей.
Итоговый вывод — это результат совместной работы:
- активного шаблона Bitrix,
- подключённых пакетов ассетов,
- значений свойств (site/section/page/user),
- выбранных
VIEWдля областей, - и набора блоков/компонентов, которые эти
VIEWвызывают.
Конфиги: уровни site/section/page/user и наследование
В вашей актуальной модели “уровни” — это прежде всего фактические файлы значений, которые участвуют в сборке страницы:
-
Site-level:
{site_dir}/simai.data/.site.property.php— глобальные значения для сайта (в том числе выборVIEWобластей черезgrid_view_*). -
Section-level + Page-level:
.property.phpв директории раздела (например,/ru/.property.php). Этот файл может содержать:- секцию
section(значения для раздела и всех вложенных разделов), - секцию
page(значения для конкретных страниц, по имени файла — и они переопределяют раздел и сайт).
- секцию
Приоритет применения такой:
- page переопределяет section,
- section переопределяет site.
Пользовательские настройки у вас чаще всего задаются через URL и хранятся в сессии браузера. Их удобно воспринимать как “временный пользовательский слой поверх файловых уровней”.
Пример: выбор VIEW областей на уровне сайта в {site_dir}/simai.data/.site.property.php:
'grid_view_header' => '005',
'grid_view_footer' => 'default',
'grid_view_home' => 'default',
'grid_view_sidebar_left' => 'default',
'grid_view_sidebar_right' => 'default',
'grid_view_main_top' => 'default',
'grid_view_main_bottom' => 'default',
Ассеты: базовые из ядра /simai, проектные — через simai.data/template и замещение конфигурации
Базовые пакеты ассетов SF4 живут на уровне ядра (в системной части) и подключаются через механизм загрузчика ассетов. На уровне проекта обычно добавляется второй слой:
- проектные файлы (CSS/JS, мета, панель и т.д.) через
{site_dir}/simai.data/template— это основной способ “докинуть своё”, не трогая ядро; - проектная конфигурация ассетов на уровне
{site_dir}/simai.data/config(когда используется в проекте) — и важное правило вашей практики: на уровне сайта конфигурация замещает системную, а не дополняет её. Это сделано специально, чтобы обновление ядра не ломало сайт: проект фиксирует свой набор пакетов и живёт с ним стабильно.
Грид: VIEW областей в simai.data/grid/view, блоки в simai.data/grid/block, выбор по коду
Грид в SF4 работает так, что “что именно собирать” определяется сохранёнными представлениями. VIEW хранится как папка:
- для
header:{site_dir}/simai.data/grid/view/header/<view_code>/ - для
footer:{site_dir}/simai.data/grid/view/footer/<view_code>/ - для
home:{site_dir}/simai.data/grid/view/home/<view_code>/ - для сайдбаров:
{site_dir}/simai.data/grid/view/sidebar/left|right/<view_code>/ - для main-top/main-bottom:
{site_dir}/simai.data/grid/view/main/top|bottom/<view_code>/
Внутри view лежит template.php, который фактически является “сохранённой конфигурацией”: он содержит готовый вызов simai:sf.grid с параметрами строк, колонок и областей. При этом view может включать условия отрисовки (например, показывать/скрывать строку по значению свойства), то есть представление не просто “фиксирует верстку”, а ещё и реагирует на настройки.
Блоки, которые использует view, выбираются по коду — обычно это имя папки блока в:
{site_dir}/simai.data/grid/block/<section>/<block_code>/
Именно это позволяет безопасно расширяться: менять конфигурацию можно через VIEW, а содержимое/шаблоны блоков — через слой grid/block.
Пример: переопределение VIEW на конкретной странице через .property.php (page-level) — чтобы у страницы был другой макет областей, чем у сайта по умолчанию:
<?php
return array(
'page' => array(
'index.php' => array(
'grid_view_header' => 'default',
'grid_view_footer' => 'default',
'grid_view_sidebar_left' => 'empty',
'grid_view_sidebar_right' => 'empty',
),
),
);
Кэш: кэш компонентов Bitrix и кэш ассетов; что делать после изменений
В жизненном цикле SF4 участвуют два типовых слоя кэширования:
- кэш Bitrix-компонентов (особенно на инфоблоках/выборках);
- кэш подключаемых ресурсов (ассеты и результаты их сборки/подключения).
Практическое правило: после изменений в simai.data (view/block/template/config) и после правок .property.php может потребоваться очистка релевантного кэша, иначе изменения будут “не видны” из-за кешированных результатов.
Чек-лист готовности (lifecycle)
На минимальной проверке “всё ли собрано правильно” удобно держать такой набор критериев:
- Активирован правильный шаблон сайта (и он подключает SF4).
- Для областей задан
VIEWна уровне сайта (и при необходимости переопределён на уровне страницы/раздела). - View по коду реально существует в
simai.data/grid/view/.../<code>/и содержитtemplate.php. - Блоки, вызываемые из view, существуют в
simai.data/grid/block/...и отдаются без ошибок. - Проектные CSS/JS подключаются через
simai.data/templateи не конфликтуют с системными. - После изменений очищен кэш (компонентов/ассетов), если обновления не проявились сразу.
- Режим редактирования гридов включается через панель SF4 (сначала общий режим редактирования, затем кнопка “включить режим редактирования гридов”), когда нужно править конфигурацию интерактивно.