календарьlink

В типовом сценарии вокруг инфоблоков строят «цепочку страниц»: список элементов → детальная карточка → (при необходимости) страницы разделов. В SF4 эти задачи закрывают компоненты семейства simai:sf.iblock.*. Практически во всех из них заложена одинаковая идея: инфоблок и элементы можно идентифицировать по ID или по коду, но в проектах SF4 обычно опираются на коды (устойчивее при миграциях и переносах).

На практике начинайте с simai:sf.iblock.list (вывод списка) и simai:sf.iblock.detail (детальная). Для списка ключевыми являются параметры источника (IBLOCK_TYPE, IDENTIFICATION_TYPE, далее IBLOCK_ID/IBLOCK_CODE, а для раздела — SECTION_ID/SECTION_CODE), параметры количества (COUNT) и сортировки (SORT_BY1, SORT_ORDER1). Если нужно фильтровать выдачу — используйте параметр FILTER_NAME и договоритесь о едином имени фильтра между фильтром и списком/таблицей/календарём.

Пример (упрощённый) связки «фильтр → список» с идентификацией по коду:

<?php
// 1) Фильтр формирует условия в $GLOBALS['newsFilter'] (имя передаём в FILTER_NAME)
$APPLICATION->IncludeComponent(
    "simai:sf.iblock.filter",
    ".default",
    [
        "IDENTIFICATION_TYPE" => "code",
        "IBLOCK_TYPE" => "news",
        "IBLOCK_CODE" => "news",
        "FILTER_NAME" => "newsFilter",
        // ...прочие параметры фильтра (зависят от шаблона/полей)
    ]
);

// 2) Список использует тот же FILTER_NAME
$APPLICATION->IncludeComponent(
    "simai:sf.iblock.list",
    "sf-news-card",
    [
        "IDENTIFICATION_TYPE" => "code",
        "IBLOCK_TYPE" => "news",
        "IBLOCK_CODE" => "news",
        "FILTER_NAME" => "newsFilter",
        "COUNT" => "12",
        "SORT_BY1" => "ACTIVE_FROM",
        "SORT_ORDER1" => "DESC",
        // ...параметры вывода/шаблона
    ]
);

Для grid/block: сборка страницы, условия показа, фон/анимации, связка с блокамиlink

Сценарий грида в SF4 — это сборка страницы (или области страницы) из представления (view) и набора блоков (block). Важно: view в SF4 — это не «просто шаблон», а сохранённая конфигурация, которую можно загрузить и получить нужную настройку сущности (область/страница/блок). Визуальный редактор сохраняет изменения в simai.data/grid/view/.../template.php, а выбор активного представления фиксируется в настройках (через .site.property.php / .property.php для соответствующего уровня).

Компонент simai:sf.grid имеет параметры, влияющие на режимы и набор доступных опций. Например, BLOCK_SECTION определяет «секцию» (область), из которой берутся блоки (вроде header, footer, sidebar, main и т.д.), а EXPERT_MODE включает расширенные настройки (по сути — «показать дополнительные поля»).

Пример подключения области грида (идея — выбрать секцию блоков для области):

<?php
$APPLICATION->IncludeComponent(
    "simai:sf.grid",
    ".default",
    [
        "BLOCK_SECTION" => "header",
        // "EXPERT_MODE" => "Y", // при необходимости расширенных настроек
    ]
);

Для feedback/forms: формы обратной связи/опросов/обращенийlink

Формы в SF4 решают сразу несколько задач: собрать поля, провалидировать, при необходимости сохранить/обработать данные и отправить уведомления. В simai:sf.feedback явно заложены настройки «как подтверждать отправку» и «куда отправлять»: параметр CONFIRMATION предлагает варианты подтверждения (капча/почта/без подтверждения), а блок почтовых параметров включает хотя бы EMAIL (адрес администратора), темы (EMAIL_ADMIN_SUBJ, EMAIL_SUBJ) и текст сообщения (EMAIL_MESSAGE).

Отдельно предусмотрен сценарий событийной отправки: USE_POST_EVENT и POST_EVENT — когда форму нужно связать с почтовым событием (и, при включённых свойствах, прокинуть значения в параметры события).

Минимальный пример:

<?php
$APPLICATION->IncludeComponent(
    "simai:sf.feedback",
    ".default",
    [
        "CONFIRMATION" => "1",          // 1 = captcha (варианты задаются в параметрах компонента)
        "EMAIL" => "admin@example.com", // куда уведомлять
        "EMAIL_ADMIN_SUBJ" => "Новая заявка",
        "EMAIL_SUBJ" => "Спасибо! Мы получили ваше сообщение",
        "EMAIL_MESSAGE" => "Ваше сообщение принято.",
        // "USE_POST_EVENT" => "Y",
        // "POST_EVENT" => "SF_FEEDBACK_FORM",
    ]
);

Для navigation/content/ui: меню, хлебные крошки, share, cookie, weather/rss, promo/bannerlink

В навигации обычно комбинируют: меню (структура разделов/страниц), «хлебные крошки», а также небольшие UI-виджеты, которые подключаются там, где они нужны (в шапке/подвале/сайдбаре/внутри блоков). Важно держать в голове, что часть этих компонентов — «визуальные», а часть тянет данные (RSS, погода), поэтому у них почти всегда есть параметры источника и кеширования.

Два показательных примера параметров:

simai:sf.rss.show использует URL (откуда читать RSS) и NUM_NEWS (сколько вывести).
simai:sf.pdf.viewer использует PDF_URL — путь/URL к PDF для отображения.

Пример для RSS:

<?php
$APPLICATION->IncludeComponent(
    "simai:sf.rss.show",
    ".default",
    [
        "URL" => "https://example.com/feed.xml",
        "NUM_NEWS" => "10",
    ]
);

Пример для PDF viewer:

<?php
$APPLICATION->IncludeComponent(
    "simai:sf.pdf.viewer",
    ".default",
    [
        "PDF_URL" => "/upload/docs/manual.pdf",
    ]
);

Для media/forms: загрузка фото/видео, списки пользователей, редактор свойствlink

Эта группа закрывает «прикладные» задачи админки/публичных форм: загрузить медиа, показать списки, дать редактор для настроек. Здесь ключевой принцип такой же: параметры определяют источник данных и сценарий, а внешний вид задаётся шаблоном компонента (и/или блоком, который его использует).

По именам компонентов видно назначение:

simai:sf.photo.add, simai:sf.video.add — добавление медиа.
simai:sf.user.list — вывод пользователей.
simai:sf.property.edit — интерфейс редактирования настроек/свойств (часто используется как служебный компонент для панели/редакторов).

Если для конкретного проекта важно зафиксировать «какие поля обязательны», «куда сохраняется», «какие права нужны» — это требует уточнения по сценарию использования (в разных решениях набор полей и политика доступа могут отличаться).

Для wizard: последовательные шаги `sf.wizard`/`sf.wizard.stage` с actionslink

Мастер в SF4 — это сценарий, который выполняется шагами (stage), а каждый шаг вызывает одно или несколько действий (actions), работающих с общим массивом данных мастера: действие берёт данные из подмассива, выполняет операцию и сохраняет результат обратно (в этот же или другой подмассив). За счёт этого мастер можно собирать как «конвейер»: проверка окружения → подготовка директорий → распаковка пакетов → импорт инфоблоков → настройка сайта → финальные сообщения.

На уровне компонентов:

simai:sf.wizard содержит скрытый параметр WIZARD_DIR и управляет выполнением (в т.ч. в AJAX-режиме, где важны AJAX_TIME_STEP и AJAX_TIME_INTERVAL).
simai:sf.wizard.stage использует WIZARD_CODE (скрытый) и служит «ступенькой» внутри мастера.

Минимальный пример (идея — подключить мастер в нужной директории):

<?php
$APPLICATION->IncludeComponent(
    "simai:sf.wizard",
    ".default",
    [
        "WIZARD_DIR" => "/simai/wizard/master/simai.sf4university/",
        "AJAX_TIME_STEP" => "10",
        "AJAX_TIME_INTERVAL" => "5",
    ]
);

Где смотреть параметры: `.parameters.php` компонента и шаблоновlink

Самый надёжный способ понимать «что можно настроить» — смотреть определения параметров:

глобальные параметры компонента: /bitrix/components/simai/<component>/.parameters.php
параметры конкретного шаблона: /bitrix/components/simai/<component>/templates/<template>/.parameters.php

Это особенно полезно для компонентов, где параметры зависят от режима (например, в iblock-компонентах переключение IDENTIFICATION_TYPE меняет набор доступных полей, а у sf.grid часть параметров появляется в EXPERT_MODE).

Примеры использования в проектеlink

Если в проекте есть демонстрационные страницы/разделы документации, используйте их как «живую витрину» настроек: там обычно уже подобраны шаблоны, параметры и связки (например, «фильтр → список», «грид → блоки», «виджеты в шапке/подвале»). В самой документации SF4 это удобно оформлять как: «что делает компонент» → «какие параметры обязательны» → «типовой пример подключения» → «типовые ошибки (кеш/права/не тот код инфоблока)».