3 августа 2018 в 14:55
Возникла специфичная задача. Опишу на общем примере:
Есть словарь "фрукты", в котором термины "яблоко, груша, банан".
Есть тип материала "овощи", в котором ноды "томаты, огурцы, свёкла".
Есть ли способ вывести одной вьюшкой это всё и отсортировать по алфавиту?
Очевидное решение использовать модуль view as field, но национальная индейская изба, не работает оно так.
Комментарии
У вьюса может быть только одна "базовая" таблица БД.
Термины таксономии (словарь) и Ноды - это две разные таблицы.
Можно конечно извернуться и объединить их через 3-и тип ноды,
или "продублировать" словарь в отдельном типе ноды (связав термины словаря и ноды)
но мне кажется, оптимальнее будет лучше продумать структуру данных.
Иначе, далее друпал станет спарринг-партнером, а не помошником-)
Это не только вьюсом, это и прямым запросом из БД не вытащить, т.к. в данном случае две таблицы даже никак не сджойнить.
Прямых запросов можно сделать 2..
А далее еще придется побороть Drupal, чтобы вывести все это дело на нужную страницу.-)
С двумя запросами можно будет сломать мозг, если будет нужна сортировка плюс пагинация.
Поэтому я и предложил лучше продумать структуру данных, чтобы не ломать мозг себе и не выносить мозги другим людям.-)
Тогда и разработка пойдет на порядок веселее и последующая поддержка менее геморнее-)
Там не JOIN, там UNION нужен.
Так, ладно, а если задачка немного проще:
Есть нода, в ней есть поле field1 типа ссылающееся на ноды. И есть поле field2, тоже ссылающееся на этот же тип материалов. Поля идентичны.
Задача вывести алфавитно отсортированный список, слегка поменяв форматирование (em) если ссылка идёт в field2.
Такое возможно?
Не однозначно понятно условие задачи.
Распишите, пожалуйста, по подробнее..
Например не понятно, что значит
и причем тут
Ну уже не особо актуально, но тем не менее:
Есть сайт https://scn.grushinka.ru/
Структура там внутри такая:
Словарь таксономии "сцены"
Тип материала "выступающий"
Тип материала "выступление"
Во втором типе есть два поля: "кто" и "кто (скрытое)" ссылающиеся на типа "выступающий".
Через поле "кто" формируется вывод программы сцен.
Теперь в чём грабли: есть индивидуальные расписания, например https://scn.grushinka.ru/people/shcherbina-aleksandr где нужно использовать и оба поля. Сейчас это реализовано через два блока.
https://scn.grushinka.ru/people/shcherbina-aleksandr
Я правильно понял, в одном случае выступление "сольное" (блок Выступления)
а в другом выступление "на концерте" (блок Разное)?
И необходимо оба типа этих выступлений выводить одним вьюсом, наверное чтобы выступления были отсортированы по дате-времени?
Я думаю, правильнее была бы такая структура:
Сущность Выступление.
Поля:
Если поле Мероприятие заполнено - Исполнитель выступает в составе концерта
Если поле Мероприятие пустое - сольное выступление
Вот и все, просто выводите вьюсом сущности Выступление с нужными критериями фильтрации.
Да, понял ты правильно, нужна сортировка не только по разным, но и по времени для самого выступающего. Тут разница задач: слушателю не особенно интересно что Саша сидит во втором туре конкурса, к примеру, а вот для него самого не помешало бы.
Та структура что ты предлагаешь - нет, оно не подходит. Дело в том что бывают выступления, когда поёт, например, Ирина Сурина, но у неё есть аккомпаниатор (которого никто не знает и оно ему не нужно чтобы знали), который вообще не только у неё, и светить его во всех концертах не надо. Т.е. нужно именно что возможность скрытого списка и открытого.
Проще простого..
Надо просто для сущности Исполнитель добавить какое-то поле, по которому его в последствии можно отфильтровывать вьюсом.
Например - поле "Роль исполнителя" с ограниченым списком значений.
Например: "вокалист", "аккомпониатор"
И где надо, вьюсом выводить всех испонителей, а где не надо только согласно роли.
Вообще, как я понял задачу, больше подходит такая структура:
Сущность "Исполнитель"
Поля:
1.ФИО исполнителя
2.Роль исполнителя: вокалист, аккомпониатор, и т.п.
... остальное по вкусу
Сущность "Коллектив" (выступающий коллектив)
Поля:
1. Состав (связь с сущностью Исполнитель) многострочное (список исполнителей)
... остальное по вкусу
Сущность "Выступление"
Поля:
1.Коллектив
2.Время (от и до)
Сущность "Мероприятие"
Поля:
1.Наименование (наименование концерта, если сольное, то просто имя Исполнителя)
1. Место (связь с сущностью Место)
2. Выступления (связь с сущностью Выступление, кол-во неограничено)
Виджет: Inline Entity Form
т.е. сущность Выступлени можно добавлять непосредственно из формы мероприятия (концерта)
... любые по необходимости
В итоге получаем объекты данных (сущности) полностью соответвтсующие реальным "объектам" (Концерт - Выступление - Коллектив -Состав)
По этим сущностям можно делать любые необходимые выборки данных (вьюсы): хоть программу выступлений полностью с нужной детализацией и группировкой.
хоть программу выступлений одного Исполнителя, будь то вокалист или аккомпониатор или руковолитель ансамбля или уборщица-)
А если надо быстро, то можно просто переименовать блоки:
Выступление - Сольное выступление
Разное - Концерты
-))
Роль выступающего может быть любой, там списком ограничиться не выйдет. К тому же начнутся чисто творческие разборки "я не аккомпаниатор, я в группе, чо меня как записали, я обиделся выступать не буду!". С творческими людьми часто бывает очень сложно, у них очень обострённые чувства, их очень легко обидеть... В абсолютном большинстве проектов такие моменты не возникают, но в данном случае треба учесть.
Вообще да, я хотел изначально сделать структуру покучерявей, но тут уже вопрос упирается в контент-менеджеров. Система не должна позволять забить полную муру. В этом году оно забивается централизованно, решили отказаться от выдачи прав руководителям сцен, но в следующем году система разграничений потребуется.
Ещё нюанс: один тот же человек может выступать в совершенно разных ролях, например здесь он главный гость на сцене, в поэтическом конкурсе его приговорили сидеть в жюри, а дуэтом с женой пошёл в основной песенный конкурс.
Сущность коллектив нужна, как объединяющая сущности исполнитель, с возможностью её пихать, это надо для групп и дуэтов и это я буду делать, собственно оно реализовано на другом моём проекте uralbards.ru, а в данном случае не было времени чтобы всех забить как надо. Ну просто упёрлись в то что ВНЕЗАПНО выяснилось что дедлайн был неделю назад, жареный петух не клюнул, а ворвался стремительным домкратом...
Это тоже не проблема.. можно исполнителю назначать несколько ролей (многострочное поле)..
Короче надо просто полностью понять "специфику" того для чего и для кого это вэб-приложение разрабатывается, и исходя из этого спланировать нужную структуру данных.
По разграничению прав..
Вобщем, по той примерной структуре, что я описал выше уже несложно разграничить права по ролям, так сказать, вертикально (по уровням иерархии - от концерта - до исполнителя)
Если необходимо разграничить доступ по горизонтали, т.е. например каждая группа контент-менеджеров "заведует" освещением концертов определенного Места и т.п. - тоже не проблема.. есть для этого специальные модули..
Короче, задачка интересная, я бы помог как минимум консультациями..
Тем более сам давно хочу вырваться на Грушу, но что-то она все невпопад по времени случается-)
Отпейсал в личку.