Помогите с навигационной линейкой (breadcrumbs)

Главные вкладки

Аватар пользователя PG PG 10 октября 2005 в 2:00

Экспериментирую с шаблоном phpbluemarine (это bluemarine, написанная под phptemplate).

Если выводится оглавление терма или нескольких сразу, то "хлебные крошки", breadcrumbs (т.е. навигационная линейка, показывающая положение текущей страницы в общей иерархии сайта) выводится нормально. Ну, разве что, стоит дублировать заголовок страницы в конце этой линейки, но, как мне кажется, это дело поправимое средствами одного лишь шаблона, без влезания в код движка.

Хуже дело обстоит с выводом конкретного нода. По умолчанию, при показе нода, breadcrumbs состоит из одной единственной ссылки, ведущей на главную страницу сайта. Понятно, откуда это растет: если нод принадлежит сразу нескольким термам одновременно, его местоположение в структуре сайта простым "урлом" не определишь. Программеры, мать их за ногу, решили пойти наиболее простым путем, поэтому раз так, все ноды теперь "не принадлежат никому", во всяком случае, их принадлежность вообще не показывается.

По мне, так решение тупое и не лучшее, особенно учитывая, что структура многих сайтов делается чисто иерархической, и нод всегда принадлежит конкретному терму.

Нельзя ли и здесь помочь делу? Путем вставления в шаблон кода, самостоятельно формирующего ссылки и текст для breadcrumbs, по аналогии с тем, как это было сделано по совету Bang в шаблоне node.tpl.php для полностью самостоятельного формирования ссылок на термы, которым принадлежит очередной выводимый заголовок нода?

Кто-нибудь может помочь и подсказать код, который бы позволил заменить "тэг" "print $breadcrumb" и который выводил бы полное расположение всех термов текущего нода в иерархии сайта?

Ну - если нод принадлежит одному терму, тогда пусть отрисовывается обычная навигационная линейка, которая бы позволила нам подняться от текущего документа на любой вышестоящий.

А если нод принадлежит нескольким термам, то пусть такие линейки рисуются для всех термов, которым он принадлежит. Почему бы и нет?

Может кто-нибудь помочь?

Комментарии

Аватар пользователя PG PG 10 октября 2005 в 2:11

Листинг кода для отрисовки списка термов, к которым относится нод, приведу сразу после того, как Аксель включит возможность выкладывания листингов (он знает эту настройку, мы с ним на эту тему уже общались).

Аватар пользователя rgb rgb 11 октября 2005 в 19:22

Приветсвую!

PG> ...по аналогии с тем, как это было сделано по совету Bang в шаблоне node.tpl.php...

2PG: Не могли бы вы указать ссылку на сообщение, о котором идёт речь? Или хотя бы тему его?

И что касается "..Листинг кода для отрисовки списка термов.." - мне его тоже интересно было бы увидеть. Буду его ждать в этой ветке форума.

По-поводу Вашего вопроса: я сам с этой проблемой столкнулся и думаю что в ближайшую неделю выделю время на её решение. Если что-то путное получится - выложу здесь.

Аватар пользователя PG PG 11 октября 2005 в 22:28

Напомню ситуацию с отрисовкой принадлежности нода к термам (актуально для ситуации, когда у нас большое количество нодов принадлежит больше чем одному терму, потому как по умолчанию список термов выводится в строчку, причем разделителем является даже не запятая - просто пробел).
.
Чтобы сделать вывод списка термов в столбик, примерно как это реализовано у 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."> &#8594;</a><BR>";
}
print implode(" ", $t);
?></span>
.
.
P.S. Редактировать шаблон надо каким-то редактором, который понимает UTF-8.
.
P.P.S. Опыт Bang нам непосредственно не поможет, т.к. она не пользовалась phptemplate, задав шаблон напрямую.

Аватар пользователя rezus rezus 11 октября 2005 в 23:38

Пример:

Словарь 1
+- Терм 1
+- Терм 2
| +- СабТерм 1
| +- Сабтерм 2
+- Терм 3

Если новость будет принадлежать "Сабтерм 1", то я так понимаю, что данный кусочек показывает только "Другие новости по теме: СабТерм 1". А чтобы сделать свою, правильную версию "хлебных крошек" нужно умудриться достать и "Терм 2". Тогда можно было бы вывести: "Главная->Терм 2->Сабтерм 1"

Аватар пользователя PG PG 12 октября 2005 в 0:03

Почти верно. Скажу больше.
.
Структура у меня следующая:
.
Словарь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 отрабатывает основываясь не на структуре словарей, а на структуре меню.

Аватар пользователя rgb rgb 12 октября 2005 в 10:58

Quote:
Т.е. - жульничество. Словарь я вообще не показываю, а вместо словаря, веду на обычную ленту оглавления терма, включающую в себя все термы этого словаря (это не очень хорошо, но Drupal не умеет показывать оглавление словаря как дОлжно, приходится это делать вручную).

Извините, но я отойду немного в сторону от темы топика и задам свой вопрос (я с Дрюпалом недавно познакомился): почему же это Вы называете "жульничеством"? Я так понял, что это в порядке вещей и, более того, это единственный способ решить задачу): у меня есть несколько типов данных (например, "новости", "организации"...), для каждого типа я задаю свои категории (словари; например, для новостей это словарь: "политика", "спорт", "образование"..., а для организаций: "образование", "здравохранение", "спортивные"...). И вот я хочу получить в навигации пункты меню:

  • Спорт
    • Спортивные новости
    • Спортивные организации
  • Образование
    • Новости образования
    • Образовательные организации
  • Организации (каталог)
    • Образование
    • Здравохранение
    • Спортивные
    • ..
  • Новости
    • Политика
    • Спорт
    • Образование
    • ..

И если пункты "Новости" и "Организации (каталог)" я могу попробовать вывести чем-то типа taxonomy_menu (хотя, не факт! а может мне не все термы из словаря нужно представлять пунктами меню! Что ж мне - заводить ещё один словарь, частично повторяющий первый?), то как быть с пунктами "Спорт" и "Образование"? IMHO только так, как Вы указали (пока другого способа я не нашёл; если есть - подскажите, плиз). И на самом деле я нахожу такой способ очень гибким и правильным, т.к. тогда получается полное абстрагирование от данных от размещения в иерархии сайта: контент мэнеджер не думает в какой пункт меню ему положить новость, а просто добавляет её и назначает ей категорию (из всех доступных категорий новостей). А то, в каком пункте меню окажется новость - его уже не заботит, за это отвечает совершенно другой человек. Короче, для меня плюс в такой организации именно то, что пункты меню не зависят от категой для каких-либо типов данных на сайте.

Извините, если длинно. Извините, если это всё выглядит бредом :-). Просто я сейчас пытаюсь понять "философию использования" Дрюпала.

Пожалуйста - прокомментируйте мои измышления. Верны ли они с Вашей точки зрения?

Quote:
Так что BreadCrums отрабатывает основываясь не на структуре словарей, а на структуре меню.

Получатся, что для того, что бы всегда иметь вылидное значение в breadcrums, надо всегда находиться "в каком-то пункте" меню. Т.е. если организовать доступ ко всем страницам сайта через меню и запретить доступ через node/XXX, то задача будет решена. Но (хотя бы теоретически) реализуемо ли это? Или всё равно придётся на какой-то странице выводить breadcrumb ручками?

Аватар пользователя PG PG 12 октября 2005 в 16:16

ОК, попробую по пунктам.
.

Quote:
почему же это Вы называете "жульничеством"?

Потому что если мы делаем иерархический сайт, его иерархию нам при настройке сайта надо прописывать дважды: один раз при описании словаря, второй раз при описании меню. Это изврат, хотя в принципе, не страшно, т.к. структура сайта, в отличие от наполнения его разделов, при нормальном функционировании сайта меняется не так уж часто.
.
Единственный способ, который позволяет формировать меню автоматически, на основе структуры словаря - taxonomy_menu - является чьей-то поделкой, причем неудачной, поскольку пункты формирующегося меню ведут не на стандартные оглавления соответствующих термов, а на собственные самопальные странички, имитирующие оглавление термов во всем, кроме поддержки RSS. А если еще учесть, что ссылки на оглавления термов там оставлены без изменений, получается, что пользователь, ползая по сайту, видит и оригиналы и подделку. Всё это очень коряво смотрится. Как только я это выяснил, понял, что taxonomy_menu - вещь не самая подходящая.
.
Плюс к этому, taxonomy_menu не показывает подразделы при просмотре разделов. Так, если у нас структура ленты новостей выглядит как
-Новости
--Новости сайта
--Новости музыки
то для друпала это получается три независимые новостные ленты, а не две. То, что они находятся в каком-то там подчинении, друпал не волнует.
.
Quote:
получается полное абстрагирование от данных от размещения в иерархии сайта: контент мэнеджер не думает в какой пункт меню ему положить новость, а просто добавляет её и назначает ей категорию (из всех доступных категорий новостей). А то, в каком пункте меню окажется новость - его уже не заботит, за это отвечает совершенно другой человек.

Ну, может быть. Но в большинстве случаев, это извращение. Обычно один пункт меню соответствует одной категории. А указанный способ удобен, если у нас некоторым пунктам меню соответствует больше одной категории.
.
Quote:
Получатся, что для того, что бы всегда иметь вылидное значение в breadcrums, надо всегда находиться “в каком-то пункте” меню.

Теперь - как я себе представляю breadcrumbs для нодов: они должны соответствовать breadcrumbs для каждого из термов, которым они принадлежат. Т.е. термы, которые определены в тот или иной пункт меню, должны показываться принадлежащими соответствующему подменю. А термы, которые никуда не определены, пусть, для простоты, не показываются вовсе.

Аватар пользователя rgb rgb 12 октября 2005 в 17:14

Quote:
Потому что если мы делаем иерархический сайт, его иерархию нам при настройке сайта надо прописывать дважды: один раз при описании словаря, второй раз при описании меню.

Ясно. Вот тут мы с Вами просто по-разному смотрим на вещи: я рассматриваю таксометрию как средство создания/поддержки категорий, в которых могут находиться (принадлежать) определённые экземпляры данных (ноды, custom типы и т.п.), а Вы, рассматриваете её (таксометрию) как способ построения структуры сайта. Так? Но этот способ не решает задачу описанную мною (и Вы это подтверждаете):
 
Quote:
А указанный способ удобен, если у нас некоторым пунктам меню соответствует больше одной категории.

И я так понимаю, что для указанной задачи, ваш (и мой) "извратный" вариант - единственное возможное решение. Так?
 
Про taxonomy_menu: спасибо за инфо. Я глубоко это дело не копал, но тоже отказался пока от его использования.
 
Quote:
Теперь - как я себе представляю breadcrumbs для нодов: они должны соответствовать breadcrumbs для каждого из термов, которым они принадлежат. Т.е. термы, которые определены в тот или иной пункт меню, должны показываться принадлежащими соответствующему подменю.

Вот тут для меня неясность образовалась: мы говорим о термах или о пунктах меню? В моём случае - это разные вещи. Другими словами: должен ли я пользовать для построения breadcrumbs API taxonomy_XXX или menu_XXX? И ещё я не понял как сейчас это дело реализовано: как соотносится значение breadcrumbs и query string? Откуда Drupal знает, что на такой-то путь (например, catalog/org/cafe) надо выставлять такое-то значение в breadcrumbs и помечать определённый пункт меню как активный?

Из того, что я уже узнал, я могу предположить, что breadcrumbs, действительно, привязяны к пункту меню, а этот самый пункт, где-то соответствует определённому значению query string.

Не занимались ли Вы разбором этого вопроса? Есть ли какая-то инфа про это? Я сам ещё просто не искал ничего по этому поводу, т.к. пока с более поверхностными вопросами разбираюсь, посему, если у Вас будет что сказать по этому поводу, я буду очень благодарен.

Аватар пользователя PG PG 12 октября 2005 в 19:52

Quote:
Ясно. Вот тут мы с Вами просто по-разному смотрим на вещи: я рассматриваю таксометрию как средство создания/поддержки категорий, в которых могут находиться (принадлежать) определённые экземпляры данных (ноды, custom типы и т.п.), а Вы, рассматриваете её (таксометрию) как способ построения структуры сайта. Так?
ОК. У нас задача: сделать сайт, имеющий две новостные ленты и статейную часть на статьи двух тематик. Предложите решение, в котором таксономия не использовалась бы для построения структуры сайта.
.
upd: Добавлю для понимания: при добавлении нового материала, место, куда он попадет мы выбираем, основываясь на структуре таксономии. Если она будет разительно отличаться от структуры сайта, это может вызвать в головах "новостников" путаницу. А может не вызвать. Smile
.
Quote:
Вот тут для меня неясность образовалась: мы говорим о термах или о пунктах меню?
Мы говорим о breadcrumbs. Меня (*почти*) устраивает его нынешняя реализация применительно к оглавлениям термов. Хочется расширить эту реализацию и на принадлежащие им ноды.
.
Quote:
Из того, что я уже узнал, я могу предположить, что breadcrumbs, действительно, привязяны к пункту меню, а этот самый пункт, где-то соответствует определённому значению query string.
Эксперименты позволяют предположить, что это так. А деталями реализации, увы, не владею: не настолько я пока силён в объектном php, чтобы свободно читать листинги исходников друпала. Sad
.
Quote:
И я так понимаю, что для указанной задачи, ваш (и мой) “извратный” вариант - единственное возможное решение. Так?
Для указанной задачи - да. Если у нас таксономия не равняется структуре, друпал их должен различать. Несмотря на это, вполне можно было предусмотреть средства, автоматически берущие ту или иную ветку таксономии со всеми подветками в качестве фрагмента структуры сайта. Taxonomy_menu примерно это и делает, правда криво, и плохо сочетаясь с другими модулями.
.
P.S. Я попробовал отвязать один из термов от меню. Его breadcrumbs тут же сменились на строчку, состоящую только из одной ссылки: на корневую страницу сайта. Так что breadcrumbs однозначно формируются именно через меню.

Аватар пользователя rgb rgb 13 октября 2005 в 9:23

Quote:
ОК. У нас задача: сделать сайт, имеющий две новостные ленты и статейную часть на статьи двух тематик. Предложите решение, в котором таксономия не использовалась бы для построения структуры сайта.

Сорри, я не понимаю вопроса: разве то, о чем Вы говорили выше (про "извратный" метод) не есть искомое решение?
 
Quote:
upd: Добавлю для понимания: при добавлении нового материала, место, куда он попадет мы выбираем, основываясь на структуре таксономии. Если она будет разительно отличаться от структуры сайта, это может вызвать в головах "новостников" путаницу. А может не вызвать.

Думаю, что не должно это вызывать путаницу. Я мыслю так: ньюс-мэнеджер должен знать только то, как добавить новость и в какую категорию её определить. А то, где и как на сайте она будет выводиться - это его не касается. Это всё потому, что (в общем случае) ф-ции ньюс-мэнеджера может выполнять человек слабо подготовленный, требования к которому нужно максимально минимизировать. У Вас другая точка зрения?
 
Quote:
Мы говорим о breadcrumbs. Меня (*почти*) устраивает его нынешняя реализация применительно к оглавлениям термов. Хочется расширить эту реализацию и на принадлежащие им ноды.

Собственно с целью реализации я и уточняю: мне надо понять - на каком наборе ф-ций реализовывать это самое "расширение". Просто в своём посте Вы говорили о термах, как о пунктах меню, я же указал, что в моём случае это разные сущьности и мне требуется уточнение - к термам привязываться или к пунктам меню.
 
Quote:
Несмотря на это, вполне можно было предусмотреть средства, автоматически берущие ту или иную ветку таксономии со всеми подветками в качестве фрагмента структуры сайта. Taxonomy_menu примерно это и делает, правда криво, и плохо сочетаясь с другими модулями.

Ок. Про Taxonomy_menu мы уже говорили и я сделал вывод, что в моём случае он не подходит. Так что предлагаю не обсуждать больше этот модуль тут Smile
 
Quote:
P.S. Я попробовал отвязать один из термов от меню. Его breadcrumbs тут же сменились на строчку, состоящую только из одной ссылки: на корневую страницу сайта. Так что breadcrumbs однозначно формируются именно через меню.

Да - я тоже пришёл к подобному заключению. Буду разбирать этот вопрос дальше.

Аватар пользователя PG PG 13 октября 2005 в 12:00

Quote:
Сорри, я не понимаю вопроса: разве то, о чем Вы говорили выше (про “извратный” метод) не есть искомое решение?

Нет, потому что там как раз структура сайта воспроизводится сперва в таксономии, потом в меню:
.
Словарь новостей
- Новости 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)
.
Что, собственно, я и назвал извратом.
.
Quote:
Ок. Про Taxonomy_menu мы уже говорили и я сделал вывод, что в моём случае он не подходит. Так что предлагаю не обсуждать больше этот модуль тут
Я просто привел его как пример того, что теоретически задача набива структуры сайта один раз, а не два - вполне решаема и можно даже умозрительно представить себе ее решение.
.
Quote:
Просто в своём посте Вы говорили о термах, как о пунктах меню, я же указал, что в моём случае это разные сущьности и мне требуется уточнение - к термам привязываться или к пунктам меню.
Искать в меню ветку, в которой встречается упоминание данного терма. Затем показать "URL" этой ветки (в каких разделах она находится), нарисовав его в пунктах меню.
Так я себе это представляю.

Аватар пользователя rgb rgb 13 октября 2005 в 13:21

Quote:
Нет, потому что там как раз структура сайта воспроизводится сперва в таксономии, потом в меню <...> Что, собственно, я и назвал извратом.

Понял. Решения пока никакого не предложу.
 
Quote:
Я просто привел его как пример того, что теоретически задача набива структуры сайта один раз, а не два - вполне решаема и можно даже умозрительно представить себе ее решение

Ясно.
 
Quote:
Искать в меню ветку, в которой встречается упоминание данного терма. Затем...

Алогоритм-то яснен, но вот тут не понял:
Quote:
нарисовав его в пунктах меню.

Как это? Просто выделить тот/те пункт(-ы) меню? Или что?

Аватар пользователя PG PG 13 октября 2005 в 16:49

Quote:
Как это? Просто выделить тот/те пункт(-ы) меню? Или что?
Нет, я имел в виду, что после того, как пункт меню, соответствующий терму, найден, дальше мы должны оперировать исключительно пунктами меню и ссылками, на которые они ведут.

Аватар пользователя PG PG 12 октября 2005 в 20:39

Quote:
И если пункты “Новости” и “Организации (каталог)” я могу попробовать вывести чем-то типа taxonomy_menu (хотя, не факт! а может мне не все термы из словаря нужно представлять пунктами меню! Что ж мне - заводить ещё один словарь, частично повторяющий первый?), то как быть с пунктами “Спорт” и “Образование”?
Внимательно посмотрел структуру. Smile
.
А что, есть жуткое желание сделать, чтобы пункты меню дублировались? Например, "Новости-Образование" и "Образование-Новости" должны ссылаться на одну и ту же страницу. Конечно, это очень круто, что мы не забываем ни о новостях, ни об образовании, но не будет ли путаться посетитель, если выяснит, что предложенные ему три двери с разными табличками ведут в одну и ту же комнату? Smile
.
Я настоятельно рекомендую продумать, для чего в реальной жизни это могло бы понадобиться. Smile

Аватар пользователя rgb rgb 13 октября 2005 в 9:49

Quote:
А что, есть жуткое желание сделать, чтобы пункты меню дублировались? Например, "Новости-Образование" и "Образование-Новости" должны ссылаться на одну и ту же страницу.

Да - есть такое желание. И это желание заказчика Smile
 
Quote:
Конечно, это очень круто, что мы не забываем ни о новостях, ни об образовании, но не будет ли путаться посетитель, если выяснит, что предложенные ему три двери с разными табличками ведут в одну и ту же комнату?

Первое, на что я обратил внимание на Drupal-сайтах была навигация. И тут (drupal.ru) я сначала не мог привыкнуть к тому, что одну и ту же информацию я могу получить, кликая по разным ссылкам. Что же это получается: Дрюпал прямо-таки провоцирует на подобную организацию навигации? Тот способ, о котором мы сейчас говорим, это ж то же самое! Или я не прав?
Отвечая на Ваш вопрос: да, я думаю, что будет путаться. Но будет это в том случае, если он пришёл на сайт и решил пройтись по всем линкам. А как часто человек пробегает по всем линкам сайта? Возможно только при первом знакомстве. Зато, какие плюсы я вижу: на сайте много разных разделов, а пользователя интерисует не всё, а только новости, или только то, что относится в спорту. Он выясняет, что, например, все материалы (новости, обзоры, анонсы и т.п.) о спорте будут доступны ему с единой страницы: http://www.site.com/sport, а все новости через http://www.site.com/news и в дальнейшем, не будет гулять по "неинтересным" для него раделам, а сразу ходить туда, куда ему интересно.
Такой способ организации, это своего рода, возможность создать несколько специализированных интерфейсов к данным на одном сайте.
Вот такой вот взгляд на вещи. Может он наивный или неверный?

Аватар пользователя PG PG 13 октября 2005 в 12:03

Quote:
Первое, на что я обратил внимание на Drupal-сайтах была навигация. И тут (drupal.ru) я сначала не мог привыкнуть к тому, что одну и ту же информацию я могу получить, кликая по разным ссылкам. Что же это получается: Дрюпал прямо-таки провоцирует на подобную организацию навигации?
Это потому что друпал не формирует структуру меню сам, а отдает ее на откуп администратору, позволяя нарисовать что хочешь и подвязать к каждому пункту любую страницу. Видимо, да - это провоцирует. Smile
.
Добавлю, что на Drupal.ru навигация просто ужасна. Ни в меню, ни в заголовке не отрисовывается положение документа. Поэтому он выглядит как кучка разрозненных документов.

Аватар пользователя rgb rgb 12 октября 2005 в 9:48

2PG: Спасибо за код.

Quote:
Опыт Bang нам непосредственно не поможет, т.к. она не пользовалась phptemplate, задав шаблон напрямую.

Собственно, я рассматриваю этот вопрос безотностительно к какому-либо шаблонному движку - мне важен сам принцип.

Аватар пользователя rgb rgb 12 октября 2005 в 17:27

В данном случае под принципом я имел ввиду тот способ (те ф-ции) которые использованы для решения задачи.
 
В что называется "прямым (плоским) php шаблоном"? Это phptemplate или шаблон для другого theme engine? Или что?
И сразу же в копилочку ещё вопрос: как кастомизировать шаблоны для phptemplate я более-менее понял, а вот как с этим делом у xtemplate-based шаблонов? Могу ли я, например, на странице (экземпляр page) переопределять те переменные, которые потом используются в темплейте? (типа {breadcrumb}, {links} и т.п.). Как я уже говорил, это возможно где-то описано, но просто я не добрался ещё к этому "где-то", посему буду благодарен за объяснение или за ссылку.

Аватар пользователя PG PG 12 октября 2005 в 17:50

1) "Плоским шаблоном" (flat template) называется случай, когда шаблон подключается не через движок, а напрямую ("сам себе движок"). В штатной поставке Drupal есть пример такого темплейта.

2) XTemplate не позволяет переопределение переменных. Всех его достоинств - что шаблоны для этого движка можно редактировать чуть ли не фронт-пейджем.

Аватар пользователя PG PG 12 октября 2005 в 20:29

Добавлю, что исторически первым появился именно этот "безтемплейтовый" движок. Затем была разработана концепция темплейтовых движков и как альтернатива ему, появился 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 (пытаются сохранить его плюсы, уйдя от его минусов).
.
Но по моему, в идее написать интерпретатор на интерпретаторе есть что-то жутко извращённое. Smile

Аватар пользователя rgb rgb 13 октября 2005 в 11:00

Спасибо за справку по движкам. Это для меня прояснило ситуацию с ними :-).
 
Про Смарти: я его не использовал, но кое-что читал и видел исходники, его использующие. Я так понял, что что-то в нём я не прочуствовал, потому как очень много народу с восторгом о нём отзываются и используют, я мне это как-то не пришлось пережить :-).
Идея там вот какая: вводится ещё один язык программирования, который можно использовать внутри HTML страниц и обзывать их темплейтами. Код того языка транслируется в "чистый" PHP, так что на выходе получается то, что было вначале истории PHP, а именно: HTML со вставками PHP (жуткое зрелище, но оно и не предназначено для редактирования человеком - этот код "только для исполнения"). Этот оттранслированный вариант кэшируется и вдальнейшем, при обращении к темплейту, при условии, что он не менялся после трансляции, выполняется напрямую (т.е. работает один PHP, без необходимости повторной трансляции Smarty->PHP). Эту технику некоторые называют "предкомпиляцией шаблона".
(1) К плюсам языка вводимого Smarty, я бы отнёс компактность некоторых конструкций:
{var} вместо &lt;?php echo htmlentities($var); ?&gt;
или
{dateVal|func1|func2|func3}" вместо &lt;?php echo func3(func2(func1($dateVal)))?&gt; /* вот тут за точность не ручаюсь - по памяти всё*/
(2) Плюсом народ так же называет "гибкую систему кэширования" (к сожалению тут сказать ничего не могу - не разбирался; а может это и есть та драгоценность, за которую его любят!? ;-))
Что ещё? (3) Плюсом можно назвать и библиотеку плагинов, идущих в поставке и написанных сторонними разработчиками.
(4) Ещё: удобную возможность расширения "языка Smarty" (этими самыми плагинами, которые могут добавлять function, modifyer и ещё block, compiler, outputfilter, shared - про эти последние у меня тоже нет понятия, для чего они нужны).
(5) Некоторые ещё назовут плюсом то, что Smarty позволяет использовать логичекие конструкции в шаблоне. Для некоторых, напротив, это будет минусом.
Что-то ещё из плюсов назвать затрудняюсь.
Из минусов:
(1) это ещё один язык программирования (YAPL), к тому же, как Вы правильно заметили - сам реализованный на интерпретируемом ЯП.
(2) синтаксис не похож на синтаксис embedded скрипта ("{}" вместо "&lt;%%>" или "&lt;?xxx ?>"), посему, для тех, кто привык к подсветке исходного кода,здесь могут быть некоторые затруднения, хотя, кажется всё-таки файлы подсветки для каких-то редакторов уже есть и (я не уверен) можно определить-таки свои открывающий-закрывающий тэги;
(3) ещё для меня минусом является неудобство править темплейты в чём-то типа Dreamweaver (кажется так это пишется? Lol и необходимость предобработки темплейта, для того, что бы увидеть "как оно выглядит с данными" (справедливости ради, скажу, что из известных мне темплейтов, этого недостатка лишёл только TAL (PHPTAL), и, в некоторой степени, XSLT)
 
Disclaimer: Это всё моё IMHO. И я не преследую целью тут флэйм разводить и холивар зачинать! Smile Буду благодарен знатокам Smarty за правки-дополнения, но в обсуждениях плюсов-минусов участия принимать не собираюсь.
 

Аватар пользователя rezus rezus 14 октября 2005 в 1:42

Чтобы не потерять интересную ссылку по хлебным крошкам, кидаю её сюда.
http://drupal.org/node/31983#comment-55960
Там пошагово объясняется, как довести до ума хлебные крошки Друпала и связать их с таксономией, а не с меню.
А вот здесь поднята проблема создания нового модуля для Друпал, который будет объединять в себе функциональность book и taxonomy, что тоже позволит правильно генерировать хлебные крошки.
http://drupal.org/node/23730
По всей видимости, разработка модуля ещё не началась (вопрос начнется ли?), но может дело сдвинется и ссылка не потеряется.

Аватар пользователя PG PG 14 октября 2005 в 10:44

Замечу, что хлебные крошки логичнее связать все-таки с меню, а не с таксономией. Поясню почему: когда у нас генерируются хлебные крошки, нам дается возможность перейти на любой вышестоящий пункт иерархии. Т.е. с сабтерма - на терм, и выше - на словарь. А Drupal, подчеркну, [b]не умеет[/b] красиво и правильно показывать словари.
.
Еще замечу, что нормального модуля надо ждать, а все прочие варианты сводятся к патчу модулей. Хотелось бы обойтись без патчей. Чтобы любое обновление версии можно было провести не задумываясь.
.
Словом - хочется максимально универсального решения. Smile Поэтому если кто-то может реализовать нормальные breadcrumbs примерно так же, как это сделано для списка термов, это будет хорошо.

Аватар пользователя Troy Troy 17 октября 2005 в 21:53

Quote:

Чтобы не потерять интересную ссылку по хлебным крошкам, кидаю её сюда.
http://drupal.org/node/31983#comment-55960
Там пошагово объясняется, как довести до ума хлебные крошки Друпала и связать их с таксономией, а не с меню.

Скажем так, не довести до ума, но максимально приблизить. Там свои косяки еще есть... Это мой пост, кстати. Очень жаль что Jeremy aka Jaza видимо модуль для ясной иерархии так и не создаст, скоро уже полгода будет как все это тянется... я помнится где-то месяц назад предлагал создать хотя бы модуль для прицепления ноды к термину, чтобы вместо "term description" использовать полноценную ноду, которую удобно редактировать/искать/комментировать/...
так вот, оказывается такой мод был создан, не я был первый кому это в голову пришло Smile
опять же by Jaza, респект ему.
http://drupal.org/node/19806
я еще не тестил, наткнулся только сейчас.