Drupal 5.0 вышел!

>Все равно по читаемости до ZPT не дотягивает :) Вопрос по 
функционалу: как будет выглядеть в smarty код, который заполняет 
нужными данными некоторое заранее определенное пространство то в 
одном шаблоне, то в другом, в зависимости от некоего условия.

Как в Смарти - не знаю, но у меня - так:

[if condition]
  [include first_template.tpl]
[else]
  [include second_template.tpl]
[end if]

Да, в предыдущем ответе очепятка. Вместо [/if] - [end if].

Хотя это неважно, синтаксис прикручивается почти любой.

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

==========
<ul id="navigation">
[loop menu_items]
  [if]<li class="selected">[text]</li>
  [else]<a href="[url]">[text]</a>
  [/if]
[end loop]
==========
чего-то непонятно, где у вас само условие проверяется? (i.selected)

>чего-то непонятно, где у вас само условие проверяется?

Сорри, описАлся:

<ul id="navigation">
[loop menu_items]
  [if selected]<li class="selected">[text]</li>
  [else]<li><a href="[url]">[text]</a></li>
  [end if]
[end loop]
</ul>

> Обращение к readonly свойству элемента "чет"/"нечет" - это не модификация, а проверка свойства.

А кем это свойство прописано? В модели оно не нужно... И никогда заранее
не известно, какие ещё свойства захочет использовать дизайнер, и какие
манипуляции с этими свойствами он захочет произвести.

> Приводите-приводите.

Дизайнер пожелал выделить каждый нечётный символ в каждом третьем
элементе массива, поданного на вход в представление... Продолжать? ;)

>А кем это свойство прописано? В модели оно не нужно...

В моделе много чего еще не нужно, например, метод size() у String. И что?

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

Либо этот "универсальный шаблонизатор" - код а-ля PHP <?=$foo?> или Perl print <<XXX "$foo" ...., но тогда владелец - ССЗБ, который не понимает, что абсолютная свобода - это не свобода, а бардак и анархия.

>И никогда заранее не известно, какие ещё свойства захочет использовать дизайнер, и какие манипуляции с этими свойствами он захочет произвести.

Всегда и везде есть ограничения. Правильный дизайн системы - компромиссный. В *nix только ламеры постоянно работают от рута, им это якобы удобно, все остальные вменяемые люди задумываются о безопасности и разделении данных, а эти понятия, по сути своей - все тот же набор органичений.

>Дизайнер пожелал выделить каждый нечётный символ в каждом третьем элементе массива, поданного на вход в представление... Продолжать? ;)

XSLT, хотя это сложно и неудобно.

Или, увы, дописать движок, чтобы он ставил флаг для каждого нечётного символа в каждом третьем элементе массива.

Либо объяснить дизайнеру, что не надо хотеть такого.

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

Ну, так вы и не поняли, что дело даже не в свойствах. Ну, вот, захотел дизайнер расставить элементы меню по параболе. И нужно ему рассчитать для каждого элемента absolute position. Где и какие свойства он должен считывать? Даёт ли такую возможность шаблонизатор? И не придётся ли мне изучать второй язык, сравнимый с php ради этого? А оно хоть чем-то оправдано?

> Вы хотите универсального шаблонизатора? Ну так его не бывает

Да, да, да, я его хочу! И он бывает такой. PHP называется...

> XSLT, хотя это сложно и неудобно. > Или, увы, дописать движок,

Ай, ай, противоречим своим же утверждениям. Не хочу XLST. Действительно сложно и неудобно. А движок переписывать - политически некорректно.

> Всегда и везде есть ограничения.

Ограничения только у нас в голове. И связаны они по большей части с инерцией мышления, устоявшимися привычками, боязнью нового.

>Ну, так вы и не поняли, что дело даже не в свойствах. Ну, вот, захотел дизайнер расставить элементы меню по параболе. >И нужно ему рассчитать для каждого элемента absolute position.

Ну так заверстайте шаблдон руками или воспользуйтесь Javascript. Или Вы предлагаете вычислять absolute position в PHP? :) :) :)

>Даёт ли такую возможность шаблонизатор?

Такую возможность не дает и PHP. Потому, что он не знает НИЧЕГО про свойства дисплея юзера.

>Да, да, да, я его хочу! И он бывает такой. PHP называется...

Да нет, не бывает универсального шаблонизатора. Бывает компромисс из удобства использования, безопасности и потребляемых ресурсов. А универсального шаблонизатора не бывает, увы.

>Ай, ай, противоречим своим же утверждениям. Не хочу XLST. Действительно сложно и неудобно. А движок переписывать - политически некорректно.

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

>Ограничения только у нас в голове. И связаны они по большей части с инерцией мышления, устоявшимися привычками, боязнью нового.

Ничего подобного. До MS DOS и MS Windows много-много лет был unix со своей системой unix permissions. В MS DOS / MS Windows от прав и ограничений unix отказались, результатом стало огромное количество вирусов и троянов. Связяно это, очевидно, с полнейшим отсутствием инерциии мышления, устоявшихся привычек, и отсутвием страха перед новизной.

>Вопрос по функционалу: как будет выглядеть в smarty код, который заполняет нужными данными некоторое заранее определенное пространство то в одном шаблоне, то в другом, в зависимости от некоего условия.

Видимо, будет соваться некий include, в зависимости от условий. Ну, или всегда можно свой лоадер подвесить (я именно такой вариант использую).

>- работает быстрее ибо писано на С++

Т.е. потребует наличия у провайдера на хосте gcc и доступа на установку модулей? :)

>и не интерпретируется каждый >раз, а используется как байткод.

А у нормальных людей и PHP не интерпретируется. И даже не компилируется каждый раз.

>- работает безопаснее ибо не интерпретируется PHP

Т.е. ты гарантируешь, что твой код надёжнее кода PHP, пропущенного через фильтр Smarty? :) Ну, тогда ты очень уверенный в себе человек :D

>Т.е. потребует наличия у провайдера на хосте gcc и доступа на установку модулей? :)

Еще раз..... У ВСЕХ ведущих хостеров РУнета gcc _доступен_. Это бред - на виртуальном хостинге на давать компилятор. Но даже если компилятора нет, ничто, ну совершенно ничто не мешает воспользоваться заранее собранным пакетом.

>А у нормальных людей и PHP не интерпретируется. И даже не компилируется каждый раз.

Вот только не надо предлагать поделия фирмы Zend.

>Т.е. ты гарантируешь, что твой код надёжнее кода PHP, пропущенного через фильтр Smarty? :) Ну, тогда ты очень уверенный в себе человек :D

Конечно, надежнее. Также, как надежнее и безопаснее код модуля PERL HTML::Template по сравнению с print <<DATA $foobar....

Более того, на этом коде построены очень высокопосещаемые проекты. Почитайте рассылки на www.lexa.ru.

Reach Editor'а в Drupal 5.0 по умолчанию никакого нет. Но есть модуль FCKeditor (my favorite) и TinyMCE (fat).

Проблэма в том, что дизайнерам никогда не хватит ни одного движка шаблонов. В друпале наиболее удачное разделение кода по уровням: ядро/модули/темы. И ОЧЕНЬ удобный API (программисты оценят). Производительность для кода такой сложности -- приемлемая.

Параноик может легко написать свой движок шаблонов для Drupal, тогда будет вам счастье -- html и php врозь.

Не говорите мне про джумлу -- я её видел/пользовался/писал под неё. Это ужас. По гибкости шаблонов она отдыхает.

Маньяки могут писать на plain php, plain html или даже на forth. Но разработка сайта на базе CMS ускоряет процесс в разы.

Ryurik

>Но разработка сайта на базе CMS ускоряет процесс в разы.

Поправка: на базе CM _F_. Framework, а не System.

> Такую возможность не дает и PHP. Потому, что он не знает НИЧЕГО про свойства дисплея юзера.

Из серии "сам понял, что сказал?" ;)

> В друпале наиболее удачное разделение кода по уровням: ядро/модули/темы. И ОЧЕНЬ удобный API (программисты оценят).

Боюсь, что нет, не оценят. Я в своё время поддался рекламным зазываниям, и сделал аж 3 сайта на нём. Да, да, плакал, кололся, но продолжал драть кактус ;) Дерьмо ваш друпал в качестве движка CMS. Блог - это у него на лбу написано, и выше головы ему не прыгнуть. Да, почти всё на нём можно сделать при желании... но какими усилиями!

>> Такую возможность не дает и PHP. Потому, что он не знает НИЧЕГО про свойства дисплея юзера.

>Из серии "сам понял, что сказал?" ;)

Я-то, как раз, понял.