9 июля 2012 в 23:36
Здравствуйте.
Подскажите: как наиболее правильно организовать взаимосвязь между двумя типами материалов, например "один ко многим". Допустим, есть тип "Магазин" с названием и адресом и тип "Товар" с названием и магазином в котором он лежит. На каждый экземпляр товара создается отдельная нода и в поле "где лежит" указывается нужный магазин. Думаю, я же не первый кто столкнулся с такой задачей, и почему в документации нет описания как правильно это организовать?
Полагаю, у типа "товар" должно быть поле, указывающее на магазин. Так вот: КАКОГО ТИПА должно быть это поле? Просто число, соответствующее номеру магазина? Нельзя ли указать впрямую - поле другого типа материала, чтобы при создании товара можно было выбрать из выпадающего списка всех магазинов, существующих на данный момент? Или нужно завести словарь таксономии для магазинов, поле в товаре должно иметь тип ссылки на термин этого, при этом при добавлении нового магазина придется добавлять еще и термин в словарь?
Как это делают правильные люди? Ведь делают же както
Цель в том, чтобы далее при просмотре материала "магазин" в содержимом возникал блок из вьюхи, показывающий список товаров в данном магазине.
Направьте меня на путь истинный пожалуйста
Спасибо
Комментарии
Используйте таксономию, либо один из этих модулей:
references, entity reference, relation
Мне кажется, в данную секунду для D7 Entity reference лучше всего. http://nodeone.se/en/using-the-reference-modules
И я... такого мнения-))
В данную секунду делаю подобие торговой площадки на Drupal 7 + Commerce..
именно так и реализовал..-))
в данном случае полезным еще будет к entity reference дополнительно http://drupal.org/project/entityreference_prepopulate
Entity reference
некоторых моментов нет которые есть в references
да еще и глючный.
relation - выполняет туже функцию что и Entity reference and Reference
?
каких именно?
D7 все сущности))
делаешь словарь "магазины" (taxonomy)
к этому типу полями все что нужно
(начиная от адреса, вывески и названия, заканчивая торговой площадью и меткой на карте)
делаешь товар и к нему соответствующий магазин тегом
хочешь - ссылку на термин
хочешь ссылку на сущность
(тут камрады выше обсуждают что лучше - попробуй обе связи и сделай выбор сам)
дале - вьюс те в руки и tid аргументом)))
multpix!
я правильно понимаю, что в таком случае придется при добавлении магазина заставлять сотрудника, добавляющего магазин - добавлять не только ноду, но еще и термин в словарь
нет. только термин.
решения со связями термин <-> нода и нода <-> нода оба имеют право на жизнь.
спасибо всем, буду осмысливать...
собственно, я почему-то ожидал друпал на уровне движка позволяет организовывать материалы как записи в таблицах реляционных БД, видимо, я слишком много хочу от друпала, это как диалап через ip-телефонию. Понимаю что надо писать своё на мускле, но времени нет совсем, надо быстро и чтоб работало..
все через это проходят...
не в 80, а в 90
а вы думаете ноды в воздухе хранятся?) в БД, как записи
Таксономия.
просто мало опыта по разным задачам,
т.е. планирование наугад ))
пробуйте разные методы, и дальнейшем выбор будет осознан
в этом случае магазин это тег таксономии
товар это материал(продукт)
так логично
создаем товар и помечаем в каком магазине лежит
удачи)
я бы так и сделал, если бы мне не нужно было, чтоб магазин тоже имел много полей и свой шаблон ноды
да, опыта к сожалению мало, но задача по-моему настолько типовая, что типовой рецепт-то должен быть, уж если не в официальной документации, то в каких-нить howto. а по факту я смотрю - все делают кто во что горазд. В общем, получение опыта в ходе изобретения велосипеда помоему скучное занятие
тс не тупи
не равняй всех по себе,
и вообще ты вопрос обсуждаешь или уже трепаться пошел?
треп и нах не нужен, и необесудь.
Сделал у себя:
1.Словарь таксономии "Каталог" - категории товаров и услуг(Словарь общий для всех Предприятий)
2.Тип материала "Предприятие" - связанный со словарем "Каталог",с возможностью множественного выбора терминов.
В общем-то выбранные термины определяют "специализацию" магазина.
К предприятию в вкладке приаттачен вьюс "Товары магазина"(для менеджеров) с экспозед-фильтром по терминам "Каталога",(выводятся только термины - связанные с магазином(Предприятием)).
Вьюс выводит товары предприятия по терминам "Каталога".
Добавлена ссылка "Добавить товар" для "вызова" самодельной формы добавления товара..
При создании товара товар автоматом привязывается к предприятию и разделу словаря "Каталог"(по которому на данный момент отфильтрованы товары)
3.Тип материала "Товар"
Связан с "Предприятием" полем связи.
Связан со словарем "Каталог"
помоему... оптимально..
можно стандартно сделать вьюсы для выбора магазинов по Категориям товаров.
Выбор товаров по магазину и категории..
и т.д.
«делаешь словарь "магазины" (taxonomy)
к этому типу полями все что нужно
(начиная от адреса, вывески и названия, заканчивая торговой площадью и меткой на карте)»
извиняюсь но я в это въехать никак не могу. имеется ввиду - элементы словаря делать с многими полями?
я ж говорю, это можно, и возможно я даже смогу потом как-то отобразить инфо о магазине, но этого мало, потому что во-первых, пример с магазинами - это лишь пример, у меня совсем не магазины и не товары, а более специфичные вещи, и связка информационных сущностей не двухуровневая а больше, и если один уровень делать таксономией, второй - типом материала, чем делать третий и четвертый? Я хочу понять общий метод, а не конкретное решение.
я уж понял, что и "магазины" и "товары" будут типом материала, и к магазинам будет словарь таксономии, содержащий список номеров магазинов, и я уже даже нашел модуль который позволит на ходу добавлять термин в словарь прямо при добавлении ноды магазина. Осталось научиться сделать вьюху которая отображаясь блоком на странице ноды сможет вытащить из ноды поле с номером магазина и взять его в качестве аргумента.
всем спасибо http://site-made.ru/drupal/views-contextual-filters-relationships-argume...