Вот столкнулся с задачей внести изменения в более чем 100 созданных представлений. Изменения для всех представлений одни - дополнительная строка в настройках "Fields" тобишь добавить поле. Может кто-нибудь рассказать как это сделать?
Я все равно не очень понял отчего с "материалом" было бы правильнее
Потому что если бы у Вас был материал во views, то добавленные в него, не надо было бы добавлять в другие views если они тоже используют это материал.
"molp" wrote:
# Используя кнопку "Импорт" добавлять полученный код для нужных представлений
Импорт затирает исходный Views - частичного нет, можно только предварительно выгрузить Views в текстовом редакторе объединить с тем что надо и загрузить все обратно.
Если это новое поле - вот Вам наглядный пример того, что надо было материал выбирать а не поля.
Это заметно прибавляет нагрузки при выводе, т.к. views в этом случае дёргает все хуки для каждого материала.
2ТС: views наследует дисплей по умолчанию, это как бы абстрактный класс в терминах ООП или просто шаблон для других дисплеев. Поэтому создавать 100 списков скорее всего не надо было, наверняка можно был обойтись и одним десятком.
Это заметно прибавляет нагрузки при выводе, т.к. views в этом случае дёргает все хуки для каждого материала.
Если нагрузка не устраивает - можно как вариант выбрать только nid - a уже в темизации использовать node_view переданный по необходимости для уменьшения нагрузки - но при этом этом опять таки достаточно изменить только эту функцию, а не все views/
Views сам вызывает node_view для всех нод. А node_view, в свою очередь, вызывает хуки.
На самом деле это всё решается знанием функционала самого views + грамотная архитектура.
Например на сайте надо сделать некоторое кол-во блоков, выводящих разные типы материалов в одинаковом формате (дата, заголовок, тизер). Очевидно, надо делать для всех этих блоков один views, на каждый блок - по дисплею с наследованием полей от default. + использовать аргументы, что может сократить кол-во дисплеев до одного-двух.
Заранее скажу что осознаю ненормальность своего решения, но другого найдено не было (в теме http://drupal.ru/node/47311 так никто и не ответил).
Итак, имеем N-ное количество категорий товаров.
Для каждой категории создано представление +1.
Каждая категория должна иметь сортировку по: названию, популярности, цене. А каждая из приведенных сортировок должна использовать логику "вверх", "вниз" (asc и desc). Итого еще +6 представлений для каждой категории.
Для каждой категории создал блок с кодом со ссылками на страницы сортировки и ограничил отображение для блоков "показывать только на" указывая соответствующие path страниц представлений.
Пока вижу только сайт Если можно то давайте, попробую разобраться.
И еще ответьте пожалуйста на вопрос в теме http://drupal.ru/node/47311 а именно возможно ли сделать то о чем я там пишу? Чтобы и Заголовок и Path и Заголовок меню и Тип материала в фильтрах
Комментарии
Если это новое поле - вот Вам наглядный пример того, что надо было материал выбирать а не поля.
Я все равно не очень понял отчего с "материалом" было бы правильнее.
Но хочу спросить конкретно. Можно ли теперь добавить поля следующим способом:
Если это так и делается то у меня вопрос по пункту 3. Какие обязательные строки кода должны присутствовать для импорта?
Потому что если бы у Вас был материал во views, то добавленные в него, не надо было бы добавлять в другие views если они тоже используют это материал.
Импорт затирает исходный Views - частичного нет, можно только предварительно выгрузить Views в текстовом редакторе объединить с тем что надо и загрузить все обратно.
Благодарю.
Это заметно прибавляет нагрузки при выводе, т.к. views в этом случае дёргает все хуки для каждого материала.
2ТС: views наследует дисплей по умолчанию, это как бы абстрактный класс в терминах ООП или просто шаблон для других дисплеев. Поэтому создавать 100 списков скорее всего не надо было, наверняка можно был обойтись и одним десятком.
Наверняка можно было, жаль никто не ответил как когда я создавал специально тему
Если нагрузка не устраивает - можно как вариант выбрать только nid - a уже в темизации использовать node_view переданный по необходимости для уменьшения нагрузки - но при этом этом опять таки достаточно изменить только эту функцию, а не все views/
Views сам вызывает node_view для всех нод. А node_view, в свою очередь, вызывает хуки.
На самом деле это всё решается знанием функционала самого views + грамотная архитектура.
Например на сайте надо сделать некоторое кол-во блоков, выводящих разные типы материалов в одинаковом формате (дата, заголовок, тизер). Очевидно, надо делать для всех этих блоков один views, на каждый блок - по дисплею с наследованием полей от default. + использовать аргументы, что может сократить кол-во дисплеев до одного-двух.
molp что у Вас реализуют
?Заранее скажу что осознаю ненормальность своего решения, но другого найдено не было (в теме http://drupal.ru/node/47311 так никто и не ответил).
Итак, имеем N-ное количество категорий товаров.
Для каждой категории создано представление +1.
Каждая категория должна иметь сортировку по: названию, популярности, цене. А каждая из приведенных сортировок должна использовать логику "вверх", "вниз" (asc и desc). Итого еще +6 представлений для каждой категории.
Для каждой категории создал блок с кодом со ссылками на страницы сортировки и ограничил отображение для блоков "показывать только на" указывая соответствующие path страниц представлений.
Получаем колличество: N*(1+6)
Вот такой ужасный способ.
категория передается через аргумент в один view см. здесь "обучение" - http://metronom.com.ua/catalogue/category/produkty/obuchenie.html, могу выгрузить настройку views для Вас
Пока вижу только сайт
Если можно то давайте, попробую разобраться.
И еще ответьте пожалуйста на вопрос в теме http://drupal.ru/node/47311 а именно возможно ли сделать то о чем я там пишу? Чтобы и Заголовок и Path и Заголовок меню и Тип материала в фильтрах
Сложись впечатление что Вы не смотрели views типа taxonomy/term/% и т.д. - начните с их изучения.