Основной принцип: правки в simai.data и .property.php, ядро не трогать
В SIMAI Framework 4 (SF4) практическая разработка решения строится вокруг идеи “проектного слоя”: всё, что относится к конкретному сайту (макеты областей, блоки, стили/скрипты, конфигурации), живёт в {site_dir}/simai.data, а настройки поведения по дереву сайта — в .property.php внутри разделов. Это позволяет обновлять платформу (simai.framework) без ручного слияния правок и держать проект в переносимом виде (dev/stage/prod).
Почти любая задача в реальном проекте сводится к одному из трёх сценариев:
- выбрать/переключить представление области (view) через
grid_view_*; - изменить/заменить блок (area-шаблон), не ломая структуру view;
- изменить настройки области или страницы через наследование
page → section → site.
Минимальная “карта, где что править” для разработчика решения:
{site_dir}/simai.data/grid/view/...— представления областей (как собирается header/footer/sidebar/main и т.д.){site_dir}/simai.data/grid/block/...— блоки (что именно выводится внутри областей){site_dir}/simai.data/template/...— проектные CSS/JS и расширение фронтенда{site_dir}/simai.data/.site.property.php— значения настроек сайта (в т.ч. активныеgrid_view_*){section_dir}/.property.php— значения настроек раздела и страниц в этой ветке
Типовые операции: выбор view, переопределение блока, настройка областей
Ниже — три операции, которые покрывают большую часть ежедневной работы.
Выбор view для области (через grid_view_*)
Представление области выбирается кодом (например default, 005, empty) и хранится как значение свойства grid_view_*. Само представление — это папка в simai.data/grid/view/<area>/<code>/.
Обычно вы действуете так:
- убедиться, что нужное представление реально существует как папка в
simai.data/grid/view/...; - выставить код представления на нужном уровне (сайт/раздел/страница);
- очистить кэш, если изменения не применились сразу.
Пример: на уровне сайта в {site_dir}/simai.data/.site.property.php:
<?php
return array(
'grid_view_header' => '005',
'grid_view_footer' => 'default',
'grid_view_sidebar_left' => 'default',
'grid_view_main_top' => 'default',
);
Пример: точечное переопределение на странице (в .property.php раздела) — меняем только header для index.php, не трогая остальной сайт:
<?php
return array(
'page' => array(
'index.php' => array(
'grid_view_header' => 'default',
'show_title' => 'N',
),
),
'section' => array(),
);
Переопределение блока (через проектную реализацию в grid/block)
Блоки подключаются из view по коду ...AREA_*_TEMPLATE. В практической разработке это означает: чтобы изменить внешний вид/логику конкретного “куска” в области, вы меняете реализацию соответствующего блока в {site_dir}/simai.data/grid/block/..., а не лезете в ядро.
Хороший “проверочный” паттерн:
- какой
AREA_*_TEMPLATEиспользуется в view? - есть ли блок с этим кодом в
simai.data/grid/block/<section>/<block_code>/? - какие параметры он ожидает (обычно видно по
.parameters.phpи тому, что читаетtemplate.php)?
Реальный пример блока проекта: {site_dir}/simai.data/grid/block/header/custom.button. Он ожидает параметры с префиксом CUSTOM.BUTTON__... и рендерит одну кнопку-ссылку.
Минимальный пример того, как этот блок подключается и настраивается из view:
"BLOCK_SECTION" => "header",
"ROW_0_COL_0_AREA_0_TEMPLATE" => "custom.button",
"ROW_0_COL_0_AREA_0__CUSTOM.BUTTON__BUTTON_TEXT" => "Подать заявку",
"ROW_0_COL_0_AREA_0__CUSTOM.BUTTON__BUTTON_LINK" => "/apply/",
"ROW_0_COL_0_AREA_0__CUSTOM.BUTTON__BUTTON_TARGET__BLANK" => "N",
"ROW_0_COL_0_AREA_0__CUSTOM.BUTTON__BUTTON_MODIFIER" => "btn btn-outline-primary",
Смысл здесь практический: вы можете использовать один и тот же блок в разных представлениях и местах, меняя только параметры, а не копируя разметку.
Настройка областей через наследование и “точечные” параметры
Большая часть “настройки областей” в SF4 — это не ручная правка шаблонов, а грамотное использование уровней:
- site задаёт базовую конфигурацию (включая активные
VIEWобластей); - section корректирует правила для ветки (например, отключает сайдбар на всех страницах раздела);
- page меняет поведение на одной странице (например, скрыть заголовок, отключить хлебные крошки, поменять header).
На практике вы быстро привыкаете делать такие изменения именно через .property.php, потому что это:
- проще ревьюить (видно, где и что меняется),
- проще поддерживать (работает по наследованию),
- проще переносить между средами.