Вы здесь

Как лучше организовать сущность Учебный класс и его оснащение?

0

Добрый день
Создаётся функционал резервирования на определенный промежуток времени учебного класса
Т.е. имеется сущность БРОНЬ и РЕСУРС (почему ресурс, потому что в будущем будет не только комната, но и другие ресурсы, такие как автомобиль, инструмент и т.п, т.е универсальное средство для создания резервирования).

У каждого класса есть свои свойства, например количество сидячих мест, наличие проектора, наличие маркерной доски и т.п.

Подскажите как лучше организовать функционал добавления свойств.
Считая, что система будет расти, не хочу каждое свойство описывать полем, т.е. чтобы в типе РЕСУРС в будущем были такие поля как

  • КОЛИЧЕСТВО МЕСТ
  • ПРОЕКТОР
  • МАРКЕРНАЯ ДОСКА
  • GPS НАВИГАТОР АВТОМОБИЛЬНЫЙ
  • РЕЙЛИНГИ НА КРЫШЕ
  • ...

Потому думаю, что может по правильному сделать некую entity reference на какой то тип материала - СВОЙСТВО РЕСУРСА в котором создавать как раз эти ноды, типа ПРОЕКТОР, МАРКЕРНАЯ ДОСКА, GPS НАВИГАТОР...

Тогда встает вопрос если допустим это так и делать, получается при создании ресурса путем перечисление связей entity reference получается эффект выделения чекбоксом свойств... тогда как быть с таким свойством как КОЛИЧЕСТВО МЕСТ, где получается выбрав его, мне нужно ещё ввести где то - какое то целое число

Посоветуйте пожалуйста

Версия Drupal: 
7.x
Вопрос задан 21.11.2017 - 13:25

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

Если без разбивки, можно проробовать, как вы и написали, entity reference, с неограниченным числом значений. Надо вам проектор - добавили, надо навигатор - тоже добавили, без лишних полей.

Комментарий оставлен 21.11.2017 - 13:49

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

не хочется дробить на типы материалу, хочу универсальный способ

Комментарий оставлен 21.11.2017 - 14:10

Тогда делайте entity reference с неограниченным числом значений

Комментарий оставлен 21.11.2017 - 22:07

Ответы

0

Лично я бы поступил следующим образом.

Потратил некоторое время и написал поле с виджетом и форматтером, которое бы представляло собой следующее:
Первый элемент - select cо списком характеристик, выбираемых, например, из словаря терминов таксономии
Второй элемент - в зависимости от значения первого элемента мог бы быть текстовой строкой, чекбоксом, тоже списком с какими-то значениями и т.д.
Хранить информацию можно или в сериализованном виде, или как-то еще.
И в этом случае задавать и хранить множество разных характеристик, используя, по сути, одно поле.

Кстати, сейчас работаю с одним зарубежным клиентом, у него тоже вводится объемная информация с зависимыми друг от друга полями и т.д. Так он, не будучи программистом, собрал это сам на базе webform c множеством разным модулей и компонентов. Дешево и сердито. Единственное, что не очень удобно - не всегда быстро сохраняется новое представление. Правда, у него пока используется виртуальный хостинг (не VPS), число компонент измеряется в сотнях, а также на сохранение навешаны хуки, rules и т.д.

Ответ дан 21.11.2017 - 19:47