Перейти к содержимому
BXWiki

Универсальные списки в 1С-Битрикс - хранилища данных без кода

Универсальные списки позволяют завести структурированное хранилище без написания кода. Это справочник, база знаний или реестр контрагентов. Разберём, как они устроены изнутри и где проходят границы применимости.

Как это работает

Всё построено поверх инфоблоков. Список - это инфоблок внутри специально выделенного типа инфоблока. Данные хранятся там же, где обычный контент, а модуль даёт поверх удобный интерфейс, публичный компонент и привязку бизнес-процессов. Поэтому первый шаг настройки - создать отдельный тип инфоблока под списки и указать его модулю.

Иерархия делается разделами. Списки поддерживают разделы, и это тот самый механизм произвольной иерархии хранения. Показ разделов переключается в интерфейсе.

У нового списка одно поле. По умолчанию есть только название, все остальные поля добавляют вручную из доступных типов.

Модуль недоступен в младших редакциях. Закладывать универсальные списки в решение для таких редакций нельзя. Там придётся использовать инфоблоки напрямую.

Бизнес-процессы подключаются к спискам штатно. Это главная причина выбирать списки вместо голых инфоблоков, когда нужны согласования и маршруты обработки.

Примеры

1. Вывод списка на сайте

$APPLICATION->IncludeComponent('bitrix:lists.list.element', '', [
    'IBLOCK_TYPE_ID' => 'lists',
    'IBLOCK_ID' => $iblockId,
    'SEF_MODE' => 'Y',
    'SEF_FOLDER' => '/services/lists/',
]);

Публичный интерфейс списка даёт просмотр, добавление и редактирование элементов без разработки. Настраивают его параметрами компонента и правами.

2. Доступ к данным из кода

Список - это инфоблок, поэтому данные читаются обычными средствами. Подходит и классическое API, и ORM инфоблока. Никакого отдельного хранилища нет, и это удобно: миграция со списка на полноценный инфоблок не требует переноса данных.

3. Когда брать список, а когда инфоблок

Список хорош, когда структуру и содержимое ведут не программисты. Это справочники, реестры и базы знаний с согласованием. Инфоблок предпочтительнее, когда данные участвуют в витрине сайта. Там нужны собственные шаблоны вывода, сложные выборки и код, а дополнительный слой интерфейса только мешает.

Справочник

ЭлементНазначениеОсобенности
Тип инфоблока под спискиконтейнер для всех списковсоздаётся отдельно и указывается модулю
Списокинфоблок внутри этого типаданные хранятся как обычный контент
Поля спискаструктура записиу нового списка есть только название
Разделыиерархия хранениявключаются в интерфейсе
Бизнес-процессысогласования и маршрутыштатная интеграция
bitrix:lists.list.elementпубличный интерфейс спискапросмотр и редактирование без кода
Права доступакто видит и меняетпо группам пользователей
Ограничение редакциймодуля нет в младшихзакладывать нельзя

Частые ошибки

Списки закладывают в проект на младшей редакции. Модуля там нет - решение придётся переделывать на инфоблоки.

Не создан отдельный тип инфоблока. Модулю нужно явно указать, в каком типе жить, иначе списки смешаются с контентом сайта.

Ждут от нового списка готовой структуры. Кроме названия полей нет, их добавляют вручную.

Через списки строят витрину сайта. Для публичного каталога и контента лучше подходят инфоблоки с собственными шаблонами вывода.

Забывают, что данные - это инфоблок. При выгрузках, обменах и правках кодом работают с инфоблоком. Отдельного хранилища под список искать не нужно.

Частые вопросы

Чем универсальный список отличается от инфоблока?

Технически ничем: список - это инфоблок в специально выделенном типе. Разница в слое поверх: модуль даёт интерфейс для ведения данных без разработки, публичный компонент и штатную привязку бизнес-процессов. Поэтому списки выбирают, когда данные ведут не программисты, а инфоблоки - когда данные участвуют в витрине и требуют своих шаблонов и выборок.

Можно ли работать с данными списка из кода?

Да, и это обычная работа с инфоблоком: классическое API или ORM инфоблока с заполненным символьным кодом. Отдельного хранилища у списков нет, поэтому переход от списка к полноценному инфоблоку не требует миграции данных - меняется только способ вывода и администрирования.

Почему в админке нет раздела списков?

Либо модуль отсутствует в вашей редакции - в младших его нет, - либо не создан и не указан тип инфоблока, в котором списки должны жить. Второй шаг легко пропустить: без него модулю негде размещать списки.

Подходят ли списки для больших объёмов данных?

Они наследуют возможности и ограничения инфоблоков, так что вопрос сводится к обычной оптимизации: индексы, версия хранения свойств, выборки без лишних полей и без запросов в цикле. Но интерфейс ведения данных рассчитан на работу человека, а не на массовые операции - для импорта и обработки больших объёмов пишут скрипты, работающие с инфоблоком напрямую.

Связанные темы

Первоисточники