16 декабря 2017 в 15:37
Есть:
тип контента, к которому привязаны 2 словаря таксономии.
Как сделать, чтобы,
- Заходишь на страницу термина словаря 1
- И на ней выводятся все термины словаря 2
- Которые привязаны к нодам, которые привязаны к этому термину словаря 1.
Т.е. что тут происходит:
- Запрос ТИД термина словаря 1
- Запрос НИД всех связанных с термином нод
- Запрос все ТИД терминов словаря 2
- Вывод на экран.
А как это сделать через Views? Настраивать связи и контексты? Что там сделать?
Комментарии
Через вьюс скорее всего никак. https://drupal.ru/node/134125 - вот тут я немного рассуждал на эту тему, но получилось очень холиварно)
Я бы попробовал через views_field_view, оно позволяет впихнуть вьюшку как поле во вьюшку. Не уверен что сработает, но попробовать стоит.
по сути нужно вывести ноды, которые привязаны к термину 1, где группировка по терминам словаря 2.
То есть 1 вьюха слишком мало запросов генерит, давайте умножим это число на количество строк?
А кеширование вьюхи разве не поможет?
Если хочется быстро - пишем самостоятельно запрос к БД. Топикстартер хотел через views, я подсказал ему вариант, который может сработать.
Кто-то не видит суть.
https://www.youtube.com/watch?v=eKYEqQk3ja8
Это уже по ходу диагноз - решать все проблемы кешированием. Кеш - не панацея. И если на то уж пошло, то при грамотной архитектуре приложения кеш практически не нужен. Тот же сайт в моём профиле. Использование кеша минимально, хотя некоторые компоненты имеют достаточно сложную архитектуру и бизнес логику.
А дивиз друпала, по ходу следующий: "Наговнотыкал? Медленно? В кеш!"
Справится views + panels
Вот интересно, как. Если можно, то хотелось бы пошаговую инструкцию.
Принципиально panels_views работате с аргументами намного более гибко чем views настройка возможна но поколдовать конечно придется. И как часто в Друпале бывает есть варинат без UI с кодом но это уже совсем другая история.
Я просто сталкивался именно с такой задачей. Полностью мышкой накликать там не получится.
Я согласен с Алексеем (Gun_dose).
Логика простая, как и писал ТС, В качестве аргумента tid термина первого словаря, по которому нужно получить НОДЫ, из которых нужна аггрегация с уникальностью по ТЕРМИНАМ второго словаря.
То есть должно получиться что то подобное:
LEFT JOIN node n ON node.voc2_term_id = t2.id // Либо CONTAINS, если множественный выбор
WHERE node.voc1_term_id = {НАШ АРГУМЕНТ} // Либо CONTAINS
DISTINCT t2.name
Обычная вьюха подобное не сделает. да и не думаю, что panels_views в качестве аргументов сможет взять id результата выборки по первому темину.
Думаю всё же подобное лучше реализовать своим модулем без всяких вьюх и панелей. ИМХО
Я делал запрос и полученные айдишники передавал в контекстный фильтр вьюхи. Но это только для гибкости темизации.
А ты оказывается ещё тот изращуга)))
Taxonomy term - вьюха идущая в коомплекте с views работает аналогичным способом
Задача решается во вьюве в одно действие. Voviko написал как действовать
В группированном вьюсе нельзя скрывать все поля. А если не скрывать, то будут ноды, сгруппированные по терминам, а не термины.
Есть нода типа Новости, 2 словаря: Разделы и Регионы. Строю вьюв, который выводит регионы, которые есть в нодах для Раздела=Спорт (tid=1). Такое же требуется? Вьюв генерирует следующий sql (Drupal 7)
FROM
{node} node
LEFT JOIN {field_data_field_regions} field_data_field_regions ON node.nid = field_data_field_regions.entity_id AND (field_data_field_regions.entity_type = 'node' AND field_data_field_regions.deleted = '0')
LEFT JOIN {taxonomy_term_data} taxonomy_term_data_field_data_field_regions ON field_data_field_regions.field_regions_tid = taxonomy_term_data_field_data_field_regions.tid
LEFT JOIN {field_data_field_news_section} field_data_field_news_section ON node.nid = field_data_field_news_section.entity_id AND (field_data_field_news_section.entity_type = 'node' AND field_data_field_news_section.deleted = '0')
LEFT JOIN {taxonomy_term_data} taxonomy_term_data_field_data_field_news_section ON field_data_field_news_section.field_news_section_tid = taxonomy_term_data_field_data_field_news_section.tid
WHERE (( (field_data_field_news_section.field_news_section_tid = '1' ) )AND(( (node.status = '1') AND (node.type IN ('news')) )))
GROUP BY field_data_field_regions_node_entity_type, field_data_field_regions_field_regions_tid
На выходе термины: Москва, Смоленская область
В ваших с вовико показаниях есть определенные расхождения. Он предлагает выводить ноды, а вы предлагаете выводить термины. Запрос довольно сложный, чтобы сразу понять, по каким сущностям сделана вьюха, и какие в ней есть связи. Лично мне интересны только эти два вопроса, а не количество действий в решении задачи.
Мне казалось, я Вовико правильно понял.
Никакой магии в запросе нет, похоже Views доработали до ума.
Картинка
В настройках агрегации что-нибудь есть?
Агрегация включена, остальные параметры дефолтные
SELECT бла бла бла FROM {node} nodeТогда вопрос, почему люди говорят одно, а копипастят другое?)) Вопросов от этого меньше не становится.
Собрал тестовую вьюху, показывает node. Агрегация нужна только при множественном значении термина.
Никаких настроек агрегации нет.
Не работает, если скрыть все поля.
Запрос сложный, и потому не каждый напишет. И самое главное, врядли кто-то лучше views это сделает, и, вероятно, задача не будет стоить того, чтобы вот так. потратить пол дня, на модуль.
В случае использования views можно скрыть лишнее через css, либо еще как извернуться.
Я бы сделал через preg_match_all
Но ведь в таком раскладе под названием термина пойдут поля всех его нод. А если у нас 50 терминов и 5000 нод? Запрашивать из базы 5000 сущностей ради вывода 50 и потом резать это в шаблонах?
https://c2n.me/3QsrPYJ.png
А вот это уже похоже то, что нужно. Только надо включить уникальность в настройках запроса и всё работает, как надо. Что характерно, этот вариант больше никто не предложил))