22 июля 2011 в 11:21
Всем привет!
У меня задумка, сделать главные страницы отделов Компании. На них должны быть:
Категории материалов (тип Вьювс - термины)
Последние новости (тип Вьювс - материалы)
Сотрудники отдела (тип Вьювс - пользователи)
Отделов около 15-ти.
А теперь вопрос: как лучше сделать (менее ресурсоемко и чтобы темизировать просто было)?
Варианты: Сделать Вьювс материалы, создать дисплеи Страница для каждого отдела, с меню. Потом создать Вьювс пользователи непонятно с какими дисплеями, наверно БЛОК и выводить на страницах отделов. Создать вьювс термины и как-то (как???) выводить на странице с Вьювс материалы.
Или же создать 15 нод, вставить все вьювсы в нее один за другим? И пользователи - нормально ли создавать 15 блоков?
Как кто думает? Боюсь наделать быдлокода...
Поиск смотрел, варианты знаю, но какой лучше? Спасибо!
В итоге создал ноды, в них добавил поля текстовые и туда вставил вьювс
Комментарии
Сделать три блока и три страницы (хоть вьюхой, хоть просто нодами). В блоках выводить контент в зависимости от того, на какой странице этот блок выводится.
блоками делать наверное)
блоки делать блоками, а страницы страницами!!!
если на одной странице надо вывести и подтермины и материалы, то материалы, на мой взгляд, страницей, а термины блоком
но отделов-то 15! как их на три страницы расхреначишь? Для каждого ссылка в меню нужна.
И блоки нужно делать в отдельном Представлении, а значит, что аргументы от страниц не подставишь)
И почему три страницы?
В блоках леко можно получить arg(x).
Ну 15 страниц можете создать. Хотя, можно и одну сделать, чтобы потом не париться. Например нода 1 для разных отделов будет доступна по таким адресам:
node/1/department_1
node/1/department_2
...
node/1/department_15
А уже в самой странице и в блоках смотрим на arg(2) и узнаем к какому отделу эта страница относится.
Спасибо! А почему нода? Все-таки в ноду views_embed_view() использовать?
Да хоть что используйте. Главное, чтобы было удобно и работоспособно.
Насколько я понял у вас будет на странице отдела основной список и несколько дополнительных по бокам, то можно использовать страницу, созданную вьюхой и на ней выводить блоки.
Спасибо, буду пробовать!
Значит по 1 Вьювс для каждого вида данных (категории-блоки 1 дисплей, новости-страницы 15 дисплеев, пользователи-блоки 1 дисплей)и в зависимости от УРЛ менять отделы. Спасибо!
Можно и 15, но это не есть верно, но это вам решать.
а как ссылки в меню сделать без страниц? я сейчас дорисую, что мне нужно, может понятней будет?
вот так.
Утяжелит сайт, н решит проблему, если я правильно уловил о чем речь
Модуль называется panels
Панели используются для таких сложных и навороченных проектов, что я даже представить не могу такой ) Все разработчики таких мега-проектов с кем я общался на слово панелс говорят чур меня чур..
Если нужно сделать различные колонки лучше темизировать.
да, панели не вариант, я их в самом начале пробовал юзать - нагрузка черезчур меня чур меня))
мозг не выдержал ?
из-за особенностей arg(), нельзя использовать только 1 ноду, придется создавать 15 нод и 15 дисплеев((
поэтому если вы находитесь на странице "blog/some-post", а ее настоящим адресом является "node/123",
то arg(1) будет равен "123", а не "some-post".
Потом что нужно чтобы у отделов страницы имели путь не node/1, а departments/some_department?
Если да, то создаете одну вьюха, а в ней 15 страниц, к каждой привязываем путь с аргументом, например departments/1, а в pathauto делаем для каждого из них свой алиас.
нет, потому что для 15 отделов нужно 15 условий для вывода, а условия работают с реальными адресами, такими, как node/1
Вы не поняли. В одной ноде, с одним реальным адресом, нельзя использовать несколько параметров arg(2), потому что этот параметр работает только с реальным адресом, не с алиасами.
Точно придется 15 нод и страниц создавать.
Во-первых давайте разберемся, вы как планируете делать страницу отдела? Нодой или вьюхой? Если вьюхой, то выше я написал как это сделать.
Если нодой, то делаете пути для первой ноды таким образом:
node/1/1
node/1/2
node/1/3
..
node/1/15
И в ноде получаете arg(3). В алиасах прописать такую комбинацию через шаблон не получится, но забить 15 алиасов вручную не такая сложная задача, как создать 15 нод и поддерживать их все в актуальном состоянии.
Вы меня уж простите, но я чего-то завис. Мне необходимо сделать вьюхой, НО все отделы должны быть доступны через меню.
Я не понял, как сделать вьювс из трех страниц, но с 15 пунктами меню. Насчет arg(3) понял, спасибо! А вот сама основа...
дык создать пустую ноду, в нее вставить вьювс и она всегда будет в актуальном состоянии, верно?
Я спрашивал не про блоки, которые будут сделаны через вьюс, а про сами страницы отделов. Что они будут из себя представлять (вьюха, нода)?
Я могу и хочу вам помочь, но сначала решите как и что вы хотите видеть, по пунктам, а я расскажу как это сделать )
1 Результат:
15 страниц сайта со своими пунктами в меню.
На страницах должны быть: темизированные ссылки на категории инструкций (таксономия), последних новостей две колонки, в правом блоке список сотрудников отдела. Больше никаких условий.
Все это я хочу сделать вьювсами. Далее уже вопрос, как грамотней и с меньшими затратами времени это сделать?
Я думаю, что нужно создать вьюху типа "Термины таксономии". В ней 15 дисплеев с типом "Страница". Это даст мне адреса типа "dept/it" и нормальные ссылки в меню.
Далее сделать вьювс типа "Пользователи" с фильтром по отделу. Добавить 15 дисплеев "Блок" и выводить их справа.
И создать тип вьювс "Материалы", там будет простая фильтрация по типу "Новость" и по термину таксономии "отдел такой-то". А дисплеев наверно тоже 15 =).
При этом мне в настройках вывода блоков придется 30 путей прописать (15 для юзеров и 15 для новостей)
Или же создать тип материала, допустим с названием "Вьювс". В нем удалить все поля, добавить текстовое поле, в котороя я буду вставлять "views_embed_view", с неограниченным количеством значений.
Тогда мне нужно будет создать 15 нод такого типа и в них скопипастить "views_embed_view($name, $display_id=blablabla)".
Но мне кажется, что эти варианты мягко говоря кривые, в связи с этим и вопрос: как решить задачу элегантно?
перечитал, вроде все понятно.:)
Так. Начнем по порядку.
Насколько я понял Отдел - это такой тип материала, к которому через CCK привязываются новости и сотрудники. Поправь, если не прав.
Делаем одну вьюху с одним дисплеем "Страница". В пути пишем "dept/%". Добавляем аргумент (со вьюхами давно не работал плотно, мог и подзабыть чего), "Материал ID", в настройках аргумента:
Если аргумента нет - скрывать представление.
Настройки проверки - разрешить только строковые аргументы.
В поля добавлям то, что надо, сохраняем.
Меню создавать будем не вьюхой (она не может создавать меню с путями типа "dept/%"), а обычным путем, заходим в меню, добавить пункт, делаем 15 пунктов на разные отделы, заменяя % на названия отделов.
Таким образом получим всего одну вьюху, показывающую по 15 разным адресам разные данные.
нет, не так. Отделы - это термины таксономии, у которых есть подтермины, по которым распиханы материалы.
Соответственно при создании новости или другого материалы мы выбираем термин и материал как бы становится материалом отдела. Пользователи отдела - это те юзеры, у которых выбрана одноименная роль "отдел ИТ" и т.д.
"Материал ID", в настройках аргумента: это значит нужно создать ноду с алиасами отделов?
Делаем одну вьюху с одним дисплеем "Страница". Какого типа Вьюха? Если отделы - это не материалы? Хотя знаешь, может мне переделать, сделать отделы материалами, заглавными страницами книги?
Даа.. как вспоминаю 6-ку, так руки трясутся, нечеловеческие трудности по связыванию пользователей, материалов и таксономии. У тебя проект уже в эксплуатации или только начинаешь? Если начинаешь, бросай 6-ку и ставь семерку - там все из коробки.
не, на семерке не работает главное: ldap-авторизация + я свой дизайн под шестерку уже сделал, все готово, кроме этого. Ладно, спасибо за помощь, может как-то попроще намучу...
Навскидку - сделай тип материала Отдел, а новости и пользователей к нему цепляй через CCK Node Reference и User Reference.
их темизировать сложнее, вместо списка юзеров вывести квадратики с фотками и несколькими полями профиля.
так вроде через вьюшку можно это вывести
Конечно можно.
а блин! не вгоняй меня в рекурсию, читай последний совет Vydrin_AP ))))
ну) в настройках поля можно указать через какую вьюшку выводить)
Это как? Что-то не помню я такой настройки в CCK поле.
документация
[module=reference_views] еще вот такой модуль нашел только что)
Знаком ) кстати неплохой туториал.
Ты имел ввиду настройки поля во вьюхе? Я подумал, что в типе материала )
и правильно подумал)
в документации там написано как использовать референсы в качестве условий, это мы умеем)) а вот модуль интересный, спасибо! а как в настройках поля вьювс выставлять? у меня такого нет вроде...
Дополнительно - Пользователи, которые можно ссылаться (View)
The list of user that can be referenced can be based on a "Views module" view but no appropriate views were found.
Note:
Only views that have fields will work for this purpose.
This will discard the "Referenceable Roles" and "Referenceable Status" settings above. Use the view's "filters" section instead.
Use the view's "fields" section to display additional informations about candidate users on user creation/edition form.
Use the view's "sort criteria" section to determine the order in which candidate users will be displayed.
это означает что у меня просто нет вьювс такого типа?
поля advanced нет разве?
угу
блин да! да! даааа!!!!!
создаем вьюху нужно типа, в настройках подходящего сск поля выбираем ее и все!!!
опа... не работает, ща посмотрим...
так же списком фамилии выводятся...
Видимо я уже лишний на этом празднике жизни ) Рустам больше меня разбирается в шестерке )
при заполнении поля работает вьюха, а при просмотре опять же обычный список, так что облом((
оставайся, вдруг Рустам устанет))
уже устал)
давно я с этим разбирался) и выбрал views_attach вместо nodereference
но в вашем случае я бы их использовал вместе, nodereference для связи, views_attach для вывода
через аттач создать вид? или как?
да через attach
спасибо, буду пробовать...