Проектирование и управление разработкой сайта на платформе «1С-Битрикс: Управление сайтом»

Атрибуты типа Список

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

На инфологической модели установлена связь кратности «один-ко-многим» между полем Важности сущности Новости и полем ID сущности СтепениВажности:

• Новости имеют СтепениВажности;
• каждая Новость обязательно имеет одну и только одну СтепеньВажности;
• может быть несколько Новостей одной и той же СтепениВажности.

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

Однако предположим, что при дальнейшем общении с заказчиком выяснилось, что степеней важности всего три, и от степени важности новости существенно зависит способ её отображения на сайте:

• новости, которые редактор посчитает самыми важными, должны выводиться на главной странице, а также автоматически включаться в выпуск рассылки;
• чуть менее важные новости тоже отображаются на главной, но в рассылку не уходят;
• наименее важные новости отображаются в разделе Новости, но не попадают на главную страницу и не уходят в рассылку.

Итак, в обозримом будущем не предполагается пополнение классификатора СтепениВажности. А если он всё-таки будет пополнен, то придётся переписывать код сайта, чтобы поддержать новые варианты важностей (например, через год работы сайта заказчик захотел, чтобы супер-важные новости отправлялись зарегистрированным пользователям в виде SMS). Более того, сущность СтепениВажности не содержит других полей, кроме ID и Наименование.

	Если классификатор имеет строго определённый, фиксированный набор значений, каждое из которых скалярно, и при добавлении в него новых элементов предполагается переработка программной части системы, то такой классификатор называется закрытым классификатором или перечислением (enumeration).

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

Использование атрибута типа Список вместо отдельного инфоблока позволяет:

• не заботиться об обновлении программного кода при перезаливке базы данных (так, если потребуется перенести блок новостной ленты в другой проект, то при добавлении степеней важности в инфоблок у них будут другие ID, а значит, придётся эти ID исправлять в коде, отвечающем за различную обработку новостей);
• экономить на запросах к базе данных (работать с одним инфоблоком значительно проще, чем с двумя);
• препятствовать изменению списка пользователями, не прибегая к дополнительным мерам.

	Внимание! Атрибут типа Список следует использовать только в том случае, если классификатор одновременно отвечает одновременно всем условиям определения закрытого классификатора.

Для обозначения в Visio атрибута типа Список (то есть атрибута, варианты значения которого ограничены заранее известным списком) следует выбрать атрибут, нажать кнопку Edit, выбрать вкладку Check, после чего в поле Value последовательно вводить варианты значений и нажимать кнопку Add.