Drupal 5.0 вышел!

Joomla посмотрим сначала?
Вдруг и про шаблоны узнаем?

> Вы видели template engine лучше, чем сам php?

если "лучше" == "удобнее в использовании", то таки да. например те же самые вышеназванные flexy && smarty. хотя если конечно проект простенький, вроде вывода статистики, етц - то да, тут наворачивать смысла нет, все средствами PHP решается. но CMS, e-commerce solutions, etc - тут однозначно нужен engine, а не мешанина из PHP и HTML.

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

А также отключить пользователей и всю динамику.
Получается статический index.html закэшированный сквидом.
Все система при этом жрет ресурсов в средний офис ;)

>Joomla посмотрим сначала? Вдруг и про шаблоны узнаем?

Может, сначала будем читать, а потом только постить?

http://www.linux.org.ru/jump-message.jsp?msgid=1743058#1743212

И win-based хостинги есть.

http://slonik-v-domene.livejournal.com/1407.html

Joomla??

я щас умру от смеха... И это называется удобно????

Хотел переезжать с php-nuke на joomla и понял что переезда не будет. Ниосилил шаблоны, а в нюке всё просто.

Разговоры о безопасности нюки в лес. Я её юзаю только для новостей. chmod и htaccess в помощь сомневающимся.

> Может, сначала будем читать, а потом только постить?

И впрямь, лучше сначала читать:
http://dev.joomla.org/content/view/1136/79/

:)

> Хотел переезжать с php-nuke на joomla и понял что переезда не будет. Ниосилил шаблоны, а в нюке всё просто.

Респект за честное признание о ниасил.
Уточнение одно - нюк с йумлой рядом не стоял по всем статьям.

Еще раз: почему я вижу в тексте "шаблона" PHP код?
Почему HTML-верстальщик имеет возможность писать внутри шаблона на PHP?

Как организовать _кеширование_ HTML, сгенерированного именно этим компонентом?

Вот пример:
<div class="bannergroup<?php echo $params->get( 'moduleclass_sfx' ) ?>">

<?php if ($footerText) : ?>
	<div class="bannerheader"><?php echo $headerText ?></div>
<?php endif;

foreach($list as $item) :

	?><div class="banneritem<?php echo $params->get( 'moduleclass_sfx' ) ?>"><?php
	echo modBannersHelper::renderBanner($params, $item);
	?><div class="clr"></div>
	</div>
<?php endforeach; ?>

<?php if ($footerText) : ?>
	<div class="bannerfooter<?php echo $params->get( 'moduleclass_sfx' ) ?>">
		 <?php echo $footerText ?>
	</div>
<?php endif; ?>
</div>

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

Ждем перевод

> почему я вижу в тексте "шаблона" PHP код?

все просто - значит это не шаблон :)

ну если покурить продукт CacheFu то никаких подобных вопросов не останется.

Интересно, как этот Drupal по сравнению с Xoops?

> Нам, обезьянам, сложно понять, как можно давать HTML-кодеру возможность править PHP код. Особенно -- учитывая отсутствие необходимости декларирования переменных.

У Вас хакер, который на сайт зуб имеет, там верстальщиком работает что-ли? Или прямо пользователям сайта темплейты даёте редактировать?

Если верстальщик имеет хотя бы подобие мозга и ему один раз заранее сказать "не трогай, сцуко, PHP дальше минимальной логики в виде if-else, foreach, htmlspecialchars, urlencode, временной переменной $i и вот этого хэша с данными" - он так и поступит.

А если мозга нет он и в Smarty каком-нибудь вычитает про {php}...{/php} (да, я знаю что оно отключаемо, но...) и туда непойми чего напихает.

>У Вас хакер, который на сайт зуб имеет, там верстальщиком работает что-ли? Или прямо пользователям сайта темплейты даёте редактировать?

Заказчик должен иметь право на изменение дизайна своего сайта. А вот лазить в код проекта - нет, не должен. Точнее, по возможности -- не должен. Смешение кода проекта и дизайна провоцирует на правки кода и, как следствие, ошибки.

>Если верстальщик имеет хотя бы подобие мозга и ему один раз заранее сказать "не трогай, сцуко, PHP дальше минимальной логики в виде if-else, foreach, htmlspecialchars, urlencode, временной переменной $i и вот этого хэша с данными" - он так и поступит.

htmlspecialchars, urlencode и т.п. можно банально ЗАБЫТЬ поставить. Каждый раз объяснять, какие переменные и функции гед и в каком шаблоне можно использовать - ужасное решение.

>А если мозга нет он и в Smarty каком-нибудь вычитает про {php}...{/php} (да, я знаю что оно отключаемо, но...) и туда непойми чего напихает.

Ключевое слово: ОТКЛЮЧЕНО. В той смеси HTML и PHP, по недоразумению своему называемой "шаблоном" можно ВСЕ. Абсолютно все, что можно в PHP. И НЕТ НИКАКОЙ ВОЗМОЖНОСТИ это отключить, вот в чем проблема. А значит, рано или поздно, в шаблон "временно" переедет половина кода проекта и останется там навсегда.

Пипец. ЛОР как багзилла для обпыхпыханных кодеров уже выступает...

На самом деле самая клёвая система шаблонов - у Django. :)

К слову о...

Сначала пошел по ссылке, с целью посмотреть что это и на чем это. В течении трех минут лазил по сайту, и нигде не нашел упоминания на каком языке оно написано.

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

Захочу ли я связываться с системой у которой такой разработчик...

> Господи, ну ПОЧЕМУ пишущий на PHP народ не в состоянии прицепить НОРМАЛЬНЫЙ движок шаблонов?

Эээ... а какой нормальный? А такой чтобы не был привязан только к PHP? (Только в xslt меня посылать пожалуйста не надо). А то те что упоминались в дискуссии пугали меня словом PHP на главной странице, и смотреть дальше уже не хотелось...

> Заказчик должен иметь право на изменение дизайна своего сайта. А, вот если сайт редактирует неквалифицированный человек "со стороны", то - да, соглашусь. Ваша правда, пожалуй.

Хотя с другой стороны заказчик, если он сам начинает редактировать код, не понимая его идеологии, и что-нибудь испортит - ССЗБ, на самом деле. Впрочем, это вопрос спорный, сколько людей столько и мнений будет.

Если разработка не на заказ для третьего лица, а для "себя" (своей фирмы или ещё как-то так) же и никто со стороны код портить не будет - такие PHP-"шаблоны" вполне себе вариант, IMHO.

> htmlspecialchars, urlencode и т.п. можно банально ЗАБЫТЬ поставить.

Как и |escape:"html". А данные бывают нужны в чистом виде - скажем, чтобы и в URL запихать и в HTML-документе вывести и в javascript передать функции. IMHO, XSS-проблемы как не крути, а все равно будут хотя бы наполовину висеть на том кто редактирует шаблон. Или я чего-то не понимаю.

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

А в чем различие тут Smarty и PHP-"шаблона"? Переменные, что они откуда-то в PHP взялись, что они через $smarty->assign() присвоены - все равно надо оговаривать будет как-то.

> А значит, рано или поздно, в шаблон "временно" переедет половина кода проекта и останется там навсегда.

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

>Эээ... а какой нормальный? А такой чтобы не был привязан только к PHP? (Только в xslt меня посылать пожалуйста не надо). А то те что упоминались в дискуссии пугали меня словом PHP на главной странице, и смотреть дальше уже не хотелось...

http://havoc.ru/products/ctpp/

C/C++/PHP/Perl

>Искать хостинг с такими параметрами только ради "кошерного разделения формы и содержания", это конечно сильно .

Мне удалось на VH настроить работу django через fastcgi.

> если "лучше" == "удобнее в использовании", то таки да. например те же самые вышеназванные flexy && smarty

Я бы сказал, что это вопрос вкуса. Мне Smarty банально кажется неудобным. Для меня нет особой разницы между <h1><?=$title?></h1> и <h1>{$title}</h1>, но во втором случае надо делать кучу лишних телодвижений.

> Заказчик должен иметь право на изменение дизайна своего сайта. А вот лазить в код проекта - нет, не должен.

Что-то у вас с логикой не то. Или заказчик покупает продукт со всеми потрохами, с исходниками и документацией на внутренние структуры и прочее (и тогда редактирует что угодно и как угодно, но на свой страх и риск), или же он покупает чёрный ящик, Который Решает Задачу. Во втором случае ему ничего не надо редактировать: он платит за то, чтобы оно работало. Надо будет дизайн поменять -- ещё раз к веб-студии придёт и ещё раз заплатит.

> htmlspecialchars, urlencode и т.п. можно банально ЗАБЫТЬ поставить.

Я придерживаюсь такой точки зрения, что ни htmlspecialchars, ни urlencode в шаблонах быть не должно. Это не задача html-верстальщика -- проверка входных данных. Они, эти данные, должны быть подготовлены для использования. И не надо писать <? if( defined('foo') && isset($bar) || count($quux): ?> ... <? endif; ?>, потому как это выражение должно быть посчитано где-нибудь подальше от шаблонов.

> Ключевое слово: ОТКЛЮЧЕНО. В той смеси HTML и PHP, по недоразумению своему называемой "шаблоном" можно ВСЕ. Абсолютно все, что можно в PHP. И НЕТ НИКАКОЙ ВОЗМОЖНОСТИ это отключить, вот в чем проблема.

В чём тут проблема? Вам мешают "лишние" возможности?

> А значит, рано или поздно, в шаблон "временно" переедет половина кода проекта и останется там навсегда.

Дятел долбит. Если дятел не долбит - значит, это плохой, негодный дятел. Если разработчик - дятел, то он и в Smarty, и в XSLT такой срач разведёт, что мама не горюй.

> Как организовать _кеширование_ HTML, сгенерированного именно этим компонентом?

Кеширование и шаблоны - это совершенно разные задачи. Поверьте, их можно не смешивать :) В сложных случаях политику кеширования "рисуют" строго под задачу, как тот же LiveJournal со своими memcached (или что у них там).

>Кеширование и шаблоны - это совершенно разные задачи. Поверьте, их можно не смешивать :) В сложных случаях политику кеширования "рисуют" строго под задачу, как тот же LiveJournal со своими memcached (или что у них там).

Livejournal - пример того, как НЕ надо разрабатывать проекты. Не путайте community, записи пользоваетелей и _техническую_реализацию_.

> Livejournal - пример того, как НЕ надо разрабатывать проекты. Не путайте community, записи пользоваетелей и _техническую_реализацию_.

Согласен. Зря они его на Perl'е писали :)

>Что-то у вас с логикой не то. Или заказчик покупает продукт со всеми потрохами, с исходниками и документацией на внутренние структуры и прочее (и тогда редактирует что угодно и как угодно, но на свой страх и риск), или же он покупает чёрный ящик, Который Решает Задачу.

У меня с логикой все отлично. Когда подавляющее большинство вебпрограммистов используют возможности mod_rewrite Apache, они не задаются вопросом, как именно _реализован_ mod_rewrite. Для них он - чёрный ящик, Который Решает Задачу.

С дизайном - все тоже самое: движок сайта для верстальщика -- чёрный ящик, Который Решает Задачу. Требовать от верстальщика квалификации вебпограммиста нет смысла. Тем более, что хорошие знатоки HTML CSS AJAX и Javascript просто так на дороге не валяются и нагружать их сверх меры - себе дороже.

>Во втором случае ему ничего не надо редактировать: он платит за то, чтобы оно работало. Надо будет дизайн поменять -- ещё раз к веб-студии придёт и ещё раз заплатит.

Платить даже за то, чтобы раз в году на неделю повесить новогоднюю обвеску сайта? Ну-ну....

>Я придерживаюсь такой точки зрения, что ни htmlspecialchars, ни urlencode в шаблонах быть не должно. Это не задача html-верстальщика -- проверка входных данных. Они, эти данные, должны быть подготовлены для использования. И не надо писать <? if( defined('foo') && isset($bar) || count($quux): ?> ... <? endif; ?>, потому как это выражение должно быть посчитано где-нибудь подальше от шаблонов.

Ну вот мы и пришли к тому, что _код_ _PHP_ внутри _шаблона_ не нужен. Вся подобная деятельность выполняется в _коде_.

>В чём тут проблема? Вам мешают "лишние" возможности?

Да, мешают. Еще мне мешают "лишние" права на файловой системе, поэтому узеру, от которого работает версервер, не дано ничего, кроме своего хоум-каталога.

> Зря они его на Perl'е писали :)

Согласен, зря.

> А _нормальные_ шаблоны (если это не статическая страничка Васи Пупкина) не могут быть без кода. Выводы списков, подсветка активных табов, сокрытие/пока элементов по условиям - это всё должно быть в нормальном шаблонном движке. При тупой подстановке переменных, много HTML придётся генерировать в коде самой системы, а это - идиотизм.

А вот и могут. Достаточный на 100% шаблонизатор состоит всего из двух функций подстановки-замещения: для скалярной переменной и для массива. И все. Этого хватает для реализации любых конструкций loop/if в шаблонах (if - это частный случай loop при числе итераций=0 или 1)

> У меня с логикой все отлично. Когда подавляющее большинство вебпрограммистов используют возможности mod_rewrite Apache, они не задаются вопросом, как именно _реализован_ mod_rewrite. Для них он - чёрный ящик, Который Решает Задачу.

"Слыш, представитель Apache Foundation, мне мануал по mod_rewrite читать влом, на те пиццот баксов - и чтоб был у меня клёвый ЧПУ". Так, что ли? Или всё-таки веб-программисты читают документацию на mod_rewrite?

> С дизайном - все тоже самое: движок сайта для верстальщика -- чёрный ящик, Который Решает Задачу.

Не-а. Это "вон та фиговина, за которую начальство отвалило кучу бабла". Или "головная боль, которую нам подсунуло начальство и с которой теперь трахаться".

> Требовать от верстальщика квалификации вебпограммиста нет смысла. Тем более, что хорошие знатоки HTML CSS AJAX и Javascript просто так на дороге не валяются и нагружать их сверх меры - себе дороже.

Окей. Хороший знаток вёрстки не может "асилить" <?=$foo?> и требует вместо этого {$foo}, что ли? Это, значит, "нагружать сверх меры"? Да от таких "знатоков" следует держаться подальше.

> Платить даже за то, чтобы раз в году на неделю повесить новогоднюю обвеску сайта? Ну-ну....

Если не хотят платить - значит, им это не нужно. В чём проблема-то? Кроме того, платить надо за действие, а не за воздух. Если сделали новогодний вариант дизайна, то его и в следующем году использовать можно будет.

А если заказчик хочет себе вариант новогодний, вариант с Днём влюблённых, вариант для 8 Марта, вариант с Пасхой и вариант с Ханукой - то платить ему придётся за весь список.

> Ну вот мы и пришли к тому, что _код_ _PHP_ внутри _шаблона_ не нужен. Вся подобная деятельность выполняется в _коде_.

Вывод переменных, ветвления и циклы всё равно нужны, иначе это уже чёрт знает что, а не шаблон. Так?

И зачем для этого изобретать велосипед? Чем <?=$foo?> хуже {$foo}?

> Еще мне мешают "лишние" права на файловой системе, поэтому узеру, от которого работает версервер, не дано ничего, кроме своего хоум-каталога.

> А вот и могут. Достаточный на 100% шаблонизатор состоит всего из двух функций подстановки-замещения: для скалярной переменной и для массива. И все. Этого хватает для реализации любых конструкций loop/if в шаблонах (if - это частный случай loop при числе итераций=0 или 1)

Да, но зачем?

> Да, но зачем?

1. для эффективности кода. 2. для простоты реализации

> 1. для эффективности кода.

Чем вариант <?=$foo?> проигрывает в эффективности коду {$foo}?

> 2. для простоты реализации

Уже реализовано самим PHP. Что может быть проще, чем include()?

>Так, что ли? Или всё-таки веб-программисты читают документацию на mod_rewrite?

Причем тут документация? Исходный код -- это НЕ документация.

Есть Черный Ящик, есть описание входных и выходных параметров (техдокументация), зачем надо видеть сам код?

Естm движок сайта (Черный Ящик), есть описание того, какие данные он генерирует (техдокументация). Есть шаблонизатор, который эти данные показывает в виде HTML/plaintext/RSS/whatever.

Поменять _дизайн_ - не обязательно сменить _функциональность_, ага?

>Окей. Хороший знаток вёрстки не может "асилить" <?=$foo?> и требует вместо этого {$foo}, что ли? Это, значит, "нагружать сверх меры"? Да от таких "знатоков" следует держаться подальше.

Хороший знаток CSS может вполне ниасилить <?if ($blah_blah === $foo_bar) ..... и прочие "странности" PHP. Ему это и не надо, на самом деле.

>Если не хотят платить - значит, им это не нужно. В чём проблема-то?

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

>Вывод переменных, ветвления и циклы всё равно нужны, иначе это уже чёрт знает что, а не шаблон. Так? И зачем для этого изобретать велосипед? Чем <?=$foo?> хуже {$foo}?

1) Все это вполне делается без PHP, со скоростью, ненамного меньшей (если не бОльшей), чем работает PHP.

2) Тем, что <?=$foo?> - это доступ к _любой_ переменной, использованной внутри движка, а не к ограниченному множеству _разрешенных_к_использованию_в_шаблоне_ переменных.

Еще - тем, что вместо <?=$foo?> можно воткнуть <? some_code(); ?> и т.д., а давать возможность писать код, ограничивая только административными мерами - плохо.

>Чем вариант <?=$foo?> проигрывает в эффективности коду {$foo}?

Тем, что что-либо сложнее {$foo} (например, вывод меню с подсветкой) в шаблонизаторе можно сделать эффекивнее, в отличие от PHP.

>Уже реализовано самим PHP. Что может быть проще, чем include()?

Include - интерпретирует код, что небезопасно.

>> 1. для эффективности кода.

Чем вариант <?=$foo?> проигрывает в эффективности коду {$foo}?

тем, что для первого варианта надо шаблон пропустить через движок PHP. У меня часть кода написана на Перл, часть на ПХП (другим разработчиком), а работает все с одними общими файлами шаблонов (и три вида представления данных - XML,RSS и XHTML). Шаблоны лежат в базе данных. Вы хоть представляете, как это реализовать с кодом в стиле <?=$foo?> ?

> Естm движок сайта (Черный Ящик), есть описание того, какие данные он генерирует (техдокументация). Есть шаблонизатор, который эти данные показывает в виде HTML/plaintext/RSS/whatever.

Объясняю ещё раз. Если заказчик покупает "чтобы был сайт", то покупает именно 1 (прописью: один) чёрный ящик - собственно сайт. То, что внутри него есть маленькие чёрные ящички, не его проблема.

> Хороший знаток CSS может вполне ниасилить <?if ($blah_blah === $foo_bar) ..... и прочие "странности" PHP. Ему это и не надо, на самом деле.

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

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

Да ради бога. Я не запрещаю, пусть вносит :) Если знает как. Если не знает и что-то сломает - сам виноват. Кстати, под словами "структура сайта" обычно подразумевают не движок и не дизайн, а вовсе даже контент.

> 1) Все это вполне делается без PHP, со скоростью, ненамного меньшей (если не бОльшей), чем работает PHP.

Заменитель PHP, написанный на PHP, работает со скоростью большей, чем сам PHP? Отсыпьте немного.

> 2) Тем, что <?=$foo?> - это доступ к _любой_ переменной, использованной внутри движка, а не к ограниченному множеству _разрешенных_к_использованию_в_шаблоне_ переменных.

http://www.lorquotes.ru/view-quote.php?id=1081

> Еще - тем, что вместо <?=$foo?> можно воткнуть <? some_code(); ?> и т.д., а давать возможность писать код, ограничивая только административными мерами - плохо

Что в этом плохого? У вас верстальщиком работает нанятый врагами хакер, который всё норовит написать на главной странице сайта "h@x0r3d by ..."?

> Тем, что что-либо сложнее {$foo} (например, вывод меню с
> подсветкой) в шаблонизаторе можно сделать эффекивнее, в 
> отличие от PHP. 

Давайте посмотрим.

<ul id="navigation">
<? foreach($menu_items as $i): ?>
   <? if($i['selected']): ?>
      <li class="selected"><?=$i['text']?></li>
   <? else: ?>
      <li><a href="<?=$i['url]?>"><?=$i['text']?></a></li&g
t;
   <? endif; ?>
<? endforeach; ?>
</ul>

Один цикл и одно ветвление.
Ваш вариант?

> У меня часть кода написана на Перл, часть на ПХП (другим разработчиком), а работает все с одними общими файлами шаблонов (и три вида представления данных - XML,RSS и XHTML). Шаблоны лежат в базе данных. Вы хоть представляете, как это реализовать с кодом в стиле <?=$foo?> ?

Вопросов больше не имею. Хоть бы шаблоны в CVS положили...

> Include - интерпретирует код, что небезопасно.

function safe_include($filename) {
  return FALSE;
}

> давать возможность писать код, ограничивая только административными мерами - плохо.

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

Обалдейте всю эту самодейтельность поддерживать. Или вы поддерживать не собирайтесь?

>> У меня часть кода написана на Перл, часть на ПХП (другим разработчиком), а работает все с одними общими файлами шаблонов (и три вида представления данных - XML,RSS и XHTML). Шаблоны лежат в базе данных. Вы хоть представляете, как это реализовать с кодом в стиле <?=$foo?> ?


> Вопросов больше не имею. Хоть бы шаблоны в CVS положили...


А смысл? Шаблоны лежат в базе и редактируются (доступные части) удаленно через web интерфейс - девочки сидят в офисе и иногда меняют контент таким образом. Все просто, эффективно и удобно... Минимум забот и программистам и дизайнеру и контент провайдерам.

>Владелец сайта может делать с ним все что угодно, вплоть до полного его уничтожения.

Угу, но пусть соответственно платит за то, чтобы программисты его поддерживали.

>Нужен ему PHP-код в шаблоне - это его право.

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

> http://havoc.ru/products/ctpp/ C/C++/PHP/Perl

Приколист. И на много хостинго разрешают подключать свой модуль к php? И что с хостингом сделают когда найдут там дырку?

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

Одно из двух: или он платит тем, кто это поддерживает, или поддерживает это сам. Если он поддерживает сам - то он сам за всё ответственен. Если он платит за поддержку - то пусть не мешает.

Видел в одной СТО прайс-лист с забавным пунктом: "дать совет слесарю, который чинит вашу машину - $20".

Людям с IQ слабо отличающимся от 0 поясню:

для Drupal есть способы "привернуть" несколько разных template engine.

читайте сайт.

(Errors on page: comment-message.js line 1: ctrl_enter is not defined).