рядаlink

В SF4 блоки редактируются не “в вакууме”, а в контексте грида: вы открываете страницу в режиме редактирования и на месте (inline) настраиваете три уровня — строку, колонку и сам блок (area-шаблон). Это важно фиксировать в документации, потому что в результате вы меняете не «шаблон страницы», а сохранённую конфигурацию представления (view).

Как это работает логически:

Редактор показывает форму на основе того, какие параметры доступны у сущности:
- у строки и колонки — системные параметры грида (активность, сетка, модификаторы, фон/маска/анимации и т.п.);
- у блока — параметры, объявленные в .parameters.php конкретного блока.
Сохранение всегда идёт в view: любые изменения, сделанные drag&drop или через inline-формы, записываются в {site_dir}/simai.data/grid/view/.../template.php.
Выбор “какой view использовать” хранится отдельно — в .site.property.php (site-уровень) и/или .property.php (section/page), через grid_view_*. Это не “хранилище конфигурации”, а “переключатель активного view-кода”.

Полезно явно описать, какие ключи вы будете встречать в сохранённом view (это помогает читать конфиг глазами):

глобальные: BLOCK_SECTION, ROW_COUNT, при наличии — EXPERT_MODE, ROW_ORDER (порядок строк);
строка: ROW_{i}_NAME, ROW_{i}_ACTIVE, ROW_{i}_FULLWIDTH, ROW_{i}_COL_COUNT, и др.;
колонка: ROW_{i}_COL_{j}_WIDTH_XL/LG/MD/SM/XS, ROW_{i}_COL_{j}_AREA_COUNT, и др.;
область/блок: ROW_{i}_COL_{j}_AREA_{k}_TEMPLATE + параметры блока, прокинутые в area-слот.

Отдельно стоит зафиксировать “инженерный” приём из практики: скрытие/показ иконок редактирования часто завязывают на свойство grid_edit_mode, которое включается через панель SF4. Поэтому в вызове грида может встречаться логика вида «если grid_edit_mode включён — не скрывать иконки».

Управление состоянием: включение/выключение блоков и их элементов через UI редактора и конфигурацию viewlink

Включение/выключение в SF4 встречается на нескольких уровнях, и важно объяснить их читателю как разные механики, а не как “одну кнопку”.

Включение/выключение строк и частей структуры грида На уровне view это обычно выражается параметрами активности и структурными счётчиками:

строка может быть выключена через ROW_{i}_ACTIVE = 'N' (строка остаётся в конфигурации, но не рендерится);
блок может “исчезать” как результат изменения структуры: вы удалили area-слот, уменьшили AREA_COUNT, или сменили AREA_*_TEMPLATE на другой код/пустой вариант, если он предусмотрен в вашей схеме.

Условия показа (логика “показывать, если…”) Для условного рендера в конфигурациях используется паттерн вида:

*_USE_CONDITION — включить условие,
*_CONDITION_PROPERTY — какое свойство проверять (например, “показывать заголовок” или “показывать баннер”), и далее сравнение/значение (если они предусмотрены для данного условия).

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

Включение/выключение “внутренних” элементов блока Это уже не про грид, а про сам блок. Если у блока в .parameters.php есть чекбоксы/флаги (например USE_FILTER, SHOW_*, *_ACTIVE — как заложено автором блока), то редактор показывает их, а значения сохраняются в view как параметры area-слота и попадают в $arBlockProperty внутри template.php блока. Этот механизм особенно заметен в блоках с “сериями” параметров: количество элементов задаётся счётчиком (*_COUNT), а дальше сохраняются пары *_CODE_n, *_VALUE_n и т.п. — всё это тоже управляется UI редактора и хранится в view.

Практическое правило для документации: редактор управляет тем, что описано параметрами — у строки/колонки это параметры грида, у блока — параметры блока. Поэтому “включить/выключить” может означать разные действия в зависимости от уровня.

Где смотреть: шаблоны редактора и JS, примеры конфигов и дефолтовlink

Чтобы разработчик мог быстро разобраться “почему UI показывает именно такие поля” и “куда оно сохраняется”, в документации стоит дать читателю короткую карту наблюдения — без привязки к внутренним реестрам, но с понятными проектными путями.

Что смотреть в проекте:

Сохранённая конфигурация представления (итог редактирования): {site_dir}/simai.data/grid/view/.../template.php Это главный артефакт визуального редактирования: именно сюда пишутся изменения.
Выбор активного view-кода для области (переключатель): {site_dir}/simai.data/.site.property.php и .../.property.php в разделах/страницах Там лежат grid_view_* (header/footer/home/sidebar/main/top/main/bottom).
Шаблон и логика конкретного блока: {site_dir}/simai.data/grid/block/.../<code>/template.php Если “что-то выводится не так”, чаще всего ответ в том, как блок читает $arBlockProperty и какие значения ему реально передали из view.
Почему редактор показывает те или иные поля блока: .parameters.php блока (в той же папке блока). Это “источник формы” для блока: типы, дефолты, refresh-логика (когда от выбора одного поля появляются другие).
Компоненты, которые обеспечивают UI редактирования блоков/настроек: В составе SF4 присутствуют отдельные компоненты для редактирования/настроек блоков и грида (например, семейство sf.block.* и sf.grid). Они и формируют интерфейс inline-правки, формы параметров и сохранение результата в view.