10 октября 2005 в 2:00
Экспериментирую с шаблоном phpbluemarine (это bluemarine, написанная под phptemplate).
Если выводится оглавление терма или нескольких сразу, то "хлебные крошки", breadcrumbs (т.е. навигационная линейка, показывающая положение текущей страницы в общей иерархии сайта) выводится нормально. Ну, разве что, стоит дублировать заголовок страницы в конце этой линейки, но, как мне кажется, это дело поправимое средствами одного лишь шаблона, без влезания в код движка.
Хуже дело обстоит с выводом конкретного нода. По умолчанию, при показе нода, breadcrumbs состоит из одной единственной ссылки, ведущей на главную страницу сайта. Понятно, откуда это растет: если нод принадлежит сразу нескольким термам одновременно, его местоположение в структуре сайта простым "урлом" не определишь. Программеры, мать их за ногу, решили пойти наиболее простым путем, поэтому раз так, все ноды теперь "не принадлежат никому", во всяком случае, их принадлежность вообще не показывается.
По мне, так решение тупое и не лучшее, особенно учитывая, что структура многих сайтов делается чисто иерархической, и нод всегда принадлежит конкретному терму.
Нельзя ли и здесь помочь делу? Путем вставления в шаблон кода, самостоятельно формирующего ссылки и текст для breadcrumbs, по аналогии с тем, как это было сделано по совету Bang в шаблоне node.tpl.php для полностью самостоятельного формирования ссылок на термы, которым принадлежит очередной выводимый заголовок нода?
Кто-нибудь может помочь и подсказать код, который бы позволил заменить "тэг" "print $breadcrumb" и который выводил бы полное расположение всех термов текущего нода в иерархии сайта?
Ну - если нод принадлежит одному терму, тогда пусть отрисовывается обычная навигационная линейка, которая бы позволила нам подняться от текущего документа на любой вышестоящий.
А если нод принадлежит нескольким термам, то пусть такие линейки рисуются для всех термов, которым он принадлежит. Почему бы и нет?
Может кто-нибудь помочь?
Комментарии
Листинг кода для отрисовки списка термов, к которым относится нод, приведу сразу после того, как Аксель включит возможность выкладывания листингов (он знает эту настройку, мы с ним на эту тему уже общались).
Если не сложно, на мыло скиньте (admin@comics.com.ua). Тоже данный вопрос интересует.
Приветсвую!
PG> ...по аналогии с тем, как это было сделано по совету Bang в шаблоне node.tpl.php...
2PG: Не могли бы вы указать ссылку на сообщение, о котором идёт речь? Или хотя бы тему его?
И что касается "..Листинг кода для отрисовки списка термов.." - мне его тоже интересно было бы увидеть. Буду его ждать в этой ветке форума.
По-поводу Вашего вопроса: я сам с этой проблемой столкнулся и думаю что в ближайшую неделю выделю время на её решение. Если что-то путное получится - выложу здесь.
Напомню ситуацию с отрисовкой принадлежности нода к термам (актуально для ситуации, когда у нас большое количество нодов принадлежит больше чем одному терму, потому как по умолчанию список термов выводится в строчку, причем разделителем является даже не запятая - просто пробел).
.
Чтобы сделать вывод списка термов в столбик, примерно как это реализовано у Bang (http://test.isi.org.ru/cp/news/topic/68), надо в шаблоне node.tpl.php заменить
.
<div class="terms">( categories: <?php print $terms ?> )</div>
.
.
на приблизительно следующий код:
.
.
<BR><span class="taxonomy"><?php
$t=array();
$o_terms=taxonomy_node_get_terms($node->nid);
foreach($o_terms as $tid=>$term) {
$t[]="<a href=\"". $pre. "/" . drupal_get_path_alias("taxonomy/term/".$tid)."\">Другие новости по теме <".$term->name."> →</a><BR>";
}
print implode(" ", $t);
?></span>
.
.
P.S. Редактировать шаблон надо каким-то редактором, который понимает UTF-8.
.
P.P.S. Опыт Bang нам непосредственно не поможет, т.к. она не пользовалась phptemplate, задав шаблон напрямую.
Пример:
Словарь 1
+- Терм 1
+- Терм 2
| +- СабТерм 1
| +- Сабтерм 2
+- Терм 3
Если новость будет принадлежать "Сабтерм 1", то я так понимаю, что данный кусочек показывает только "Другие новости по теме: СабТерм 1". А чтобы сделать свою, правильную версию "хлебных крошек" нужно умудриться достать и "Терм 2". Тогда можно было бы вывести: "Главная->Терм 2->Сабтерм 1"
Почти верно. Скажу больше.
.
Структура у меня следующая:
.
Словарь1
-Терм 1
-Терм 2
.
В меню у меня написано:
.
Меню "Сайт":
-Словарь 1 (taxonomy/term/1+2)
--Терм 1 (taxonomy/term/1)
--Терм 2 (taxonomy/term/2)
.
Т.е. - жульничество. Словарь я вообще не показываю, а вместо словаря, веду на обычную ленту оглавления терма, включающую в себя все термы этого словаря (это не очень хорошо, но Drupal не умеет показывать оглавление словаря как дОлжно, приходится это делать вручную).
.
Так вот: в указанной ситуации стандартный BreadCrumb правильно отрабатывает, показывая на странице с оглавлением второго терма ссылки
.
Главная » Словарь 1
.
где "Словарь 1" ссылается на taxonomy/term/1+2.
.
Так что BreadCrums отрабатывает основываясь не на структуре словарей, а на структуре меню.
Извините, но я отойду немного в сторону от темы топика и задам свой вопрос (я с Дрюпалом недавно познакомился): почему же это Вы называете "жульничеством"? Я так понял, что это в порядке вещей и, более того, это единственный способ решить задачу): у меня есть несколько типов данных (например, "новости", "организации"...), для каждого типа я задаю свои категории (словари; например, для новостей это словарь: "политика", "спорт", "образование"..., а для организаций: "образование", "здравохранение", "спортивные"...). И вот я хочу получить в навигации пункты меню:
И если пункты "Новости" и "Организации (каталог)" я могу попробовать вывести чем-то типа taxonomy_menu (хотя, не факт! а может мне не все термы из словаря нужно представлять пунктами меню! Что ж мне - заводить ещё один словарь, частично повторяющий первый?), то как быть с пунктами "Спорт" и "Образование"? IMHO только так, как Вы указали (пока другого способа я не нашёл; если есть - подскажите, плиз). И на самом деле я нахожу такой способ очень гибким и правильным, т.к. тогда получается полное абстрагирование от данных от размещения в иерархии сайта: контент мэнеджер не думает в какой пункт меню ему положить новость, а просто добавляет её и назначает ей категорию (из всех доступных категорий новостей). А то, в каком пункте меню окажется новость - его уже не заботит, за это отвечает совершенно другой человек. Короче, для меня плюс в такой организации именно то, что пункты меню не зависят от категой для каких-либо типов данных на сайте.
Извините, если длинно. Извините, если это всё выглядит бредом :-). Просто я сейчас пытаюсь понять "философию использования" Дрюпала.
Пожалуйста - прокомментируйте мои измышления. Верны ли они с Вашей точки зрения?
Получатся, что для того, что бы всегда иметь вылидное значение в breadcrums, надо всегда находиться "в каком-то пункте" меню. Т.е. если организовать доступ ко всем страницам сайта через меню и запретить доступ через node/XXX, то задача будет решена. Но (хотя бы теоретически) реализуемо ли это? Или всё равно придётся на какой-то странице выводить breadcrumb ручками?
ОК, попробую по пунктам.
.
Потому что если мы делаем иерархический сайт, его иерархию нам при настройке сайта надо прописывать дважды: один раз при описании словаря, второй раз при описании меню. Это изврат, хотя в принципе, не страшно, т.к. структура сайта, в отличие от наполнения его разделов, при нормальном функционировании сайта меняется не так уж часто.
.
Единственный способ, который позволяет формировать меню автоматически, на основе структуры словаря - taxonomy_menu - является чьей-то поделкой, причем неудачной, поскольку пункты формирующегося меню ведут не на стандартные оглавления соответствующих термов, а на собственные самопальные странички, имитирующие оглавление термов во всем, кроме поддержки RSS. А если еще учесть, что ссылки на оглавления термов там оставлены без изменений, получается, что пользователь, ползая по сайту, видит и оригиналы и подделку. Всё это очень коряво смотрится. Как только я это выяснил, понял, что taxonomy_menu - вещь не самая подходящая.
.
Плюс к этому, taxonomy_menu не показывает подразделы при просмотре разделов. Так, если у нас структура ленты новостей выглядит как
-Новости
--Новости сайта
--Новости музыки
то для друпала это получается три независимые новостные ленты, а не две. То, что они находятся в каком-то там подчинении, друпал не волнует.
.
Ну, может быть. Но в большинстве случаев, это извращение. Обычно один пункт меню соответствует одной категории. А указанный способ удобен, если у нас некоторым пунктам меню соответствует больше одной категории.
.
Теперь - как я себе представляю breadcrumbs для нодов: они должны соответствовать breadcrumbs для каждого из термов, которым они принадлежат. Т.е. термы, которые определены в тот или иной пункт меню, должны показываться принадлежащими соответствующему подменю. А термы, которые никуда не определены, пусть, для простоты, не показываются вовсе.
Ясно. Вот тут мы с Вами просто по-разному смотрим на вещи: я рассматриваю таксометрию как средство создания/поддержки категорий, в которых могут находиться (принадлежать) определённые экземпляры данных (ноды, custom типы и т.п.), а Вы, рассматриваете её (таксометрию) как способ построения структуры сайта. Так? Но этот способ не решает задачу описанную мною (и Вы это подтверждаете):
И я так понимаю, что для указанной задачи, ваш (и мой) "извратный" вариант - единственное возможное решение. Так?
Про taxonomy_menu: спасибо за инфо. Я глубоко это дело не копал, но тоже отказался пока от его использования.
Вот тут для меня неясность образовалась: мы говорим о термах или о пунктах меню? В моём случае - это разные вещи. Другими словами: должен ли я пользовать для построения breadcrumbs API taxonomy_XXX или menu_XXX? И ещё я не понял как сейчас это дело реализовано: как соотносится значение breadcrumbs и query string? Откуда Drupal знает, что на такой-то путь (например, catalog/org/cafe) надо выставлять такое-то значение в breadcrumbs и помечать определённый пункт меню как активный?
Из того, что я уже узнал, я могу предположить, что breadcrumbs, действительно, привязяны к пункту меню, а этот самый пункт, где-то соответствует определённому значению query string.
Не занимались ли Вы разбором этого вопроса? Есть ли какая-то инфа про это? Я сам ещё просто не искал ничего по этому поводу, т.к. пока с более поверхностными вопросами разбираюсь, посему, если у Вас будет что сказать по этому поводу, я буду очень благодарен.
.
upd: Добавлю для понимания: при добавлении нового материала, место, куда он попадет мы выбираем, основываясь на структуре таксономии. Если она будет разительно отличаться от структуры сайта, это может вызвать в головах "новостников" путаницу. А может не вызвать.
.
Мы говорим о breadcrumbs. Меня (*почти*) устраивает его нынешняя реализация применительно к оглавлениям термов. Хочется расширить эту реализацию и на принадлежащие им ноды.
.
Эксперименты позволяют предположить, что это так. А деталями реализации, увы, не владею: не настолько я пока силён в объектном php, чтобы свободно читать листинги исходников друпала.
.
Для указанной задачи - да. Если у нас таксономия не равняется структуре, друпал их должен различать. Несмотря на это, вполне можно было предусмотреть средства, автоматически берущие ту или иную ветку таксономии со всеми подветками в качестве фрагмента структуры сайта. Taxonomy_menu примерно это и делает, правда криво, и плохо сочетаясь с другими модулями.
.
P.S. Я попробовал отвязать один из термов от меню. Его breadcrumbs тут же сменились на строчку, состоящую только из одной ссылки: на корневую страницу сайта. Так что breadcrumbs однозначно формируются именно через меню.
Сорри, я не понимаю вопроса: разве то, о чем Вы говорили выше (про "извратный" метод) не есть искомое решение?
Думаю, что не должно это вызывать путаницу. Я мыслю так: ньюс-мэнеджер должен знать только то, как добавить новость и в какую категорию её определить. А то, где и как на сайте она будет выводиться - это его не касается. Это всё потому, что (в общем случае) ф-ции ньюс-мэнеджера может выполнять человек слабо подготовленный, требования к которому нужно максимально минимизировать. У Вас другая точка зрения?
Собственно с целью реализации я и уточняю: мне надо понять - на каком наборе ф-ций реализовывать это самое "расширение". Просто в своём посте Вы говорили о термах, как о пунктах меню, я же указал, что в моём случае это разные сущьности и мне требуется уточнение - к термам привязываться или к пунктам меню.
Ок. Про Taxonomy_menu мы уже говорили и я сделал вывод, что в моём случае он не подходит. Так что предлагаю не обсуждать больше этот модуль тут
Да - я тоже пришёл к подобному заключению. Буду разбирать этот вопрос дальше.
Нет, потому что там как раз структура сайта воспроизводится сперва в таксономии, потом в меню:
.
Словарь новостей
- Новости 1 (Term 1)
- Новости 2 (Term 2)
Словарь статей
- Статьи 1 (Term 3)
- Статьи 2 (Term 4)
.
Меню сайта:
- Новости (taxonomy/term/1+2)
-- Новости 1 (taxonomy/term/1)
-- Новости 2 (taxonomy/term/2)
- Статьи (taxonomy/term/3+4)
-- Статьи 1 (taxonomy/term/3)
-- Статьи 2 (taxonomy/term/4)
.
Что, собственно, я и назвал извратом.
.
Я просто привел его как пример того, что теоретически задача набива структуры сайта один раз, а не два - вполне решаема и можно даже умозрительно представить себе ее решение.
.
Искать в меню ветку, в которой встречается упоминание данного терма. Затем показать "URL" этой ветки (в каких разделах она находится), нарисовав его в пунктах меню.
Так я себе это представляю.
Понял. Решения пока никакого не предложу.
Ясно.
Алогоритм-то яснен, но вот тут не понял:
Как это? Просто выделить тот/те пункт(-ы) меню? Или что?
.
А что, есть жуткое желание сделать, чтобы пункты меню дублировались? Например, "Новости-Образование" и "Образование-Новости" должны ссылаться на одну и ту же страницу. Конечно, это очень круто, что мы не забываем ни о новостях, ни об образовании, но не будет ли путаться посетитель, если выяснит, что предложенные ему три двери с разными табличками ведут в одну и ту же комнату?
.
Я настоятельно рекомендую продумать, для чего в реальной жизни это могло бы понадобиться.
Да - есть такое желание. И это желание заказчика
Первое, на что я обратил внимание на Drupal-сайтах была навигация. И тут (drupal.ru) я сначала не мог привыкнуть к тому, что одну и ту же информацию я могу получить, кликая по разным ссылкам. Что же это получается: Дрюпал прямо-таки провоцирует на подобную организацию навигации? Тот способ, о котором мы сейчас говорим, это ж то же самое! Или я не прав?
Отвечая на Ваш вопрос: да, я думаю, что будет путаться. Но будет это в том случае, если он пришёл на сайт и решил пройтись по всем линкам. А как часто человек пробегает по всем линкам сайта? Возможно только при первом знакомстве. Зато, какие плюсы я вижу: на сайте много разных разделов, а пользователя интерисует не всё, а только новости, или только то, что относится в спорту. Он выясняет, что, например, все материалы (новости, обзоры, анонсы и т.п.) о спорте будут доступны ему с единой страницы: http://www.site.com/sport, а все новости через http://www.site.com/news и в дальнейшем, не будет гулять по "неинтересным" для него раделам, а сразу ходить туда, куда ему интересно.
Такой способ организации, это своего рода, возможность создать несколько специализированных интерфейсов к данным на одном сайте.
Вот такой вот взгляд на вещи. Может он наивный или неверный?
.
Добавлю, что на Drupal.ru навигация просто ужасна. Ни в меню, ни в заголовке не отрисовывается положение документа. Поэтому он выглядит как кучка разрозненных документов.
2PG: Спасибо за код.
Собственно, я рассматриваю этот вопрос безотностительно к какому-либо шаблонному движку - мне важен сам принцип.
Принципы там везде разные. У прямого (плоского) php шаблона совершенно другой принцип.
В данном случае под принципом я имел ввиду тот способ (те ф-ции) которые использованы для решения задачи.
В что называется "прямым (плоским) php шаблоном"? Это phptemplate или шаблон для другого theme engine? Или что?
И сразу же в копилочку ещё вопрос: как кастомизировать шаблоны для phptemplate я более-менее понял, а вот как с этим делом у xtemplate-based шаблонов? Могу ли я, например, на странице (экземпляр page) переопределять те переменные, которые потом используются в темплейте? (типа {breadcrumb}, {links} и т.п.). Как я уже говорил, это возможно где-то описано, но просто я не добрался ещё к этому "где-то", посему буду благодарен за объяснение или за ссылку.
1) "Плоским шаблоном" (flat template) называется случай, когда шаблон подключается не через движок, а напрямую ("сам себе движок"). В штатной поставке Drupal есть пример такого темплейта.
2) XTemplate не позволяет переопределение переменных. Всех его достоинств - что шаблоны для этого движка можно редактировать чуть ли не фронт-пейджем.
(1) themes/chameleon/chameleon.theme - это он. Я понял. Спасибо.
(2) Ясно.
Добавлю, что исторически первым появился именно этот "безтемплейтовый" движок. Затем была разработана концепция темплейтовых движков и как альтернатива ему, появился XTemplate. Потом, видимо, сообразили, что полный отказ от PHP в шаблонах - это уже чересчур, и написали движок PHPTemplate, который, в силу сбалансированности простоты и гибкости получил наибольшее распространение. Правда, в дистрибутивах Drupal, по умолчанию по прежнему включен XTemplate.
.
Сейчас вот новый движок появился, [url=http://drupal.org/project/Theme%20engines]Smarty[/url]. Вот [url=http://smarty.php.net/manual/en/what.is.smarty.php]краткое описание на английском[/url], если кому интересно.
.
Если честно, я с этой штукой еще не игрался. Было бы неплохо, если кто-нибудь из присутствующих может вкратце рассказать о Смарти и о том, чем он отличается от прочих движков. Насколько я понял из описания, это сильно продвинутый вариант XTemplate (пытаются сохранить его плюсы, уйдя от его минусов).
.
Но по моему, в идее написать интерпретатор на интерпретаторе есть что-то жутко извращённое.
Спасибо за справку по движкам. Это для меня прояснило ситуацию с ними :-).
и необходимость предобработки темплейта, для того, что бы увидеть "как оно выглядит с данными" (справедливости ради, скажу, что из известных мне темплейтов, этого недостатка лишёл только TAL (PHPTAL), и, в некоторой степени, XSLT)
Буду благодарен знатокам Smarty за правки-дополнения, но в обсуждениях плюсов-минусов участия принимать не собираюсь.
Про Смарти: я его не использовал, но кое-что читал и видел исходники, его использующие. Я так понял, что что-то в нём я не прочуствовал, потому как очень много народу с восторгом о нём отзываются и используют, я мне это как-то не пришлось пережить :-).
Идея там вот какая: вводится ещё один язык программирования, который можно использовать внутри HTML страниц и обзывать их темплейтами. Код того языка транслируется в "чистый" PHP, так что на выходе получается то, что было вначале истории PHP, а именно: HTML со вставками PHP (жуткое зрелище, но оно и не предназначено для редактирования человеком - этот код "только для исполнения"). Этот оттранслированный вариант кэшируется и вдальнейшем, при обращении к темплейту, при условии, что он не менялся после трансляции, выполняется напрямую (т.е. работает один PHP, без необходимости повторной трансляции Smarty->PHP). Эту технику некоторые называют "предкомпиляцией шаблона".
(1) К плюсам языка вводимого Smarty, я бы отнёс компактность некоторых конструкций:
{var}вместо<?php echo htmlentities($var); ?>или
{dateVal|func1|func2|func3}"вместо<?php echo func3(func2(func1($dateVal)))?>/* вот тут за точность не ручаюсь - по памяти всё*/(2) Плюсом народ так же называет "гибкую систему кэширования" (к сожалению тут сказать ничего не могу - не разбирался; а может это и есть та драгоценность, за которую его любят!? ;-))
Что ещё? (3) Плюсом можно назвать и библиотеку плагинов, идущих в поставке и написанных сторонними разработчиками.
(4) Ещё: удобную возможность расширения "языка Smarty" (этими самыми плагинами, которые могут добавлять function, modifyer и ещё block, compiler, outputfilter, shared - про эти последние у меня тоже нет понятия, для чего они нужны).
(5) Некоторые ещё назовут плюсом то, что Smarty позволяет использовать логичекие конструкции в шаблоне. Для некоторых, напротив, это будет минусом.
Что-то ещё из плюсов назвать затрудняюсь.
Из минусов:
(1) это ещё один язык программирования (YAPL), к тому же, как Вы правильно заметили - сам реализованный на интерпретируемом ЯП.
(2) синтаксис не похож на синтаксис embedded скрипта ("
{}" вместо "<%%>" или "<?xxx ?>"), посему, для тех, кто привык к подсветке исходного кода,здесь могут быть некоторые затруднения, хотя, кажется всё-таки файлы подсветки для каких-то редакторов уже есть и (я не уверен) можно определить-таки свои открывающий-закрывающий тэги;(3) ещё для меня минусом является неудобство править темплейты в чём-то типа Dreamweaver (кажется так это пишется?
Disclaimer: Это всё моё IMHO. И я не преследую целью тут флэйм разводить и холивар зачинать!
Чтобы не потерять интересную ссылку по хлебным крошкам, кидаю её сюда.
http://drupal.org/node/31983#comment-55960
Там пошагово объясняется, как довести до ума хлебные крошки Друпала и связать их с таксономией, а не с меню.
А вот здесь поднята проблема создания нового модуля для Друпал, который будет объединять в себе функциональность book и taxonomy, что тоже позволит правильно генерировать хлебные крошки.
http://drupal.org/node/23730
По всей видимости, разработка модуля ещё не началась (вопрос начнется ли?), но может дело сдвинется и ссылка не потеряется.
Замечу, что хлебные крошки логичнее связать все-таки с меню, а не с таксономией. Поясню почему: когда у нас генерируются хлебные крошки, нам дается возможность перейти на любой вышестоящий пункт иерархии. Т.е. с сабтерма - на терм, и выше - на словарь. А Drupal, подчеркну, [b]не умеет[/b] красиво и правильно показывать словари.
Поэтому если кто-то может реализовать нормальные breadcrumbs примерно так же, как это сделано для списка термов, это будет хорошо.
.
Еще замечу, что нормального модуля надо ждать, а все прочие варианты сводятся к патчу модулей. Хотелось бы обойтись без патчей. Чтобы любое обновление версии можно было провести не задумываясь.
.
Словом - хочется максимально универсального решения.
Скажем так, не довести до ума, но максимально приблизить. Там свои косяки еще есть... Это мой пост, кстати. Очень жаль что Jeremy aka Jaza видимо модуль для ясной иерархии так и не создаст, скоро уже полгода будет как все это тянется... я помнится где-то месяц назад предлагал создать хотя бы модуль для прицепления ноды к термину, чтобы вместо "term description" использовать полноценную ноду, которую удобно редактировать/искать/комментировать/...
так вот, оказывается такой мод был создан, не я был первый кому это в голову пришло
опять же by Jaza, респект ему.
http://drupal.org/node/19806
я еще не тестил, наткнулся только сейчас.