Drupal написан без разделения HTML и кода. Опять для правки и переверстки HTML придется вызывать PHP-кодера?
SQL-запросы захардкожены в виде "SELECT n.nid, n.created FROM {node} n ...." что не дает ни нормальной переносимости ни скорости, потому, что запрос каждый раз парзится на предмет подстановки имен таблиц.
Полно несоответствий в дизайне запросов - кое-где сравнение ведется по текстовому имени -- "n.type = 'blog'", а кое-где - по числовому ID -- "n.status = 1".
>да тут надо вопрос иначе ставить. существуют ли в природе нормальные web cms в том числе на php
CMS нужны для низко и среднебюджетных проектов. Когда денег хватает только на хостинг или хостинг+дизайн. Соответственно, берется некое "общее" решение, на него натягивается очередной скин и выдается как готовый проект.
При этом, зачастую, имеющаяся CMS подходит не полностью и долго и нудно затачивается под данный проект.
Ни о какой производительности или расширяемости речь не идет (не только в PHP, а, ИМХО, в любой CMS). Потому, что общее решение -- это всегда нечто среднее из многих функциональностей, а компромисс всегда плох.
CMS, в которой нет разделения кода и дизайна - не CMS по определению. Да, можно написать проект, который будет совмещать в себе код и представление. Но вот называть его CMS - увы.
>Вот почему Joomla рулит:
>http://www.joomla.org/content/view/2618/1/
<ul>
<?php foreach ($list as $item) : ?>
<li>
<a href="<?php echo $item->link; ?>">
<?php echo $item->text; ?>
</a>
</li>
<?php endforeach; ?>
</ul>
Господи, ну ПОЧЕМУ пишущий на PHP народ не в состоянии прицепить
НОРМАЛЬНЫЙ движок шаблонов?
Или это в генах писателя на PHP - обязательно вкрутить в HTML исполняемый код?
Дядя. Не будь голословным. Весь HTML код в друпале спокойно переопределяеться в теме. К примеру есть функция theme_hello() { echo '<div class="hello">hello</div>'; } Если используем phptemlate: переопределяем функцию как phptemplate_theme_hello() в файле phptemlate.tpl { echo '<div class="myhello">myhello</div>'; } И ни какой модификации кода не нужно. Всё переопределяеться. На практике переопределяеться функции 4-5. Можно и без пх переопределять (смотря как theme engine): theme_hello.html: <div class="myhello">myhello</div> - Друпал вещь и находка. Вот в джумле да... Там мрак.
Ну выставить его не голой попой в инет, а через Squid и вопрос скорости решается сам собой. Жруч потому что это крутится поверх сервера приложений Zope питоновского.
>Господи, ну ПОЧЕМУ пишущий на PHP народ не в состоянии прицепить НОРМАЛЬНЫЙ движок шаблонов?
Нормальный движок шаблонов - Smarty.
>обязательно вкрутить в HTML исполняемый код?
А _нормальные_ шаблоны (если это не статическая страничка Васи Пупкина) не могут быть без кода. Выводы списков, подсветка активных табов, сокрытие/пока элементов по условиям - это всё должно быть в нормальном шаблонном движке. При тупой подстановке переменных, много HTML придётся генерировать в коде самой системы, а это - идиотизм.
>И ни какой модификации кода не нужно. Всё переопределяеться.
Вот это и называется - смешивать код и HTML. Всё равно дизайнеру приходится давать доступ к HTML. А потом удивляются, почему на PHP столь ненадёжные проекты пишут. Не в языке дело, а в башках идеологов проектов.
>Ну выставить его не голой попой в инет, а через Squid и вопрос скорости решается сам собой. Жруч потому что это крутится поверх сервера приложений Zope питоновского.
Это если вид сайта не зависит от пользователя.
Если же у нас требуется авторизация, например, для форума, блога или гостевой, никакое кеширование не поможет.
>А _нормальные_ шаблоны (если это не статическая страничка Васи
Пупкина) не могут быть без кода.
Неправда. Подсветку можно сделать, например, вот так:
[loop main_menu]
[if active] <b>[title]</b> [else] [title] [end if]
[/end_loop]
Фанаты XSLT могут привести пример, как это сделать на XSL, это не
намного сложнее.
>Выводы списков, подсветка активных табов, сокрытие/пока элементов по
условиям - это всё должно быть в нормальном шаблонном движке.
Для этог НЕ нужен _исполнимый_код_. Достаточно только выразительного
движка шаблонизатора.
>При тупой подстановке переменных, много HTML придётся генерировать в
коде самой системы, а это - идиотизм.
Тупая подстановка переменных ушла еще в 2000 году.
Могу ошибаться, но когда страница создается разными частями CMS (ну типовой пример это всякие-меню шапка, footer и форум в основной части) то Plone может кешировать результат работы разных своих модулей (в нашем примере это всё кроме самого форума, хотя и в самом форуме можно например закешировать панельку с кнопочками "ответить, цитировать", если можно как-то выделить процесс её генерации), таким образом время создания странички сильно сокращается.
Под кешированием в данном посте я имею ввиду что не вызывается питон и данный участок страницы не генерируется, а просто подставляется результат предыдущий генерации в итоговую страницу.
FLEXY очень неплох. чем грешит Смарти - там логики очень дофига в шаблонах. чем хорош FLEXY - минимум логики, только самое нужное + заточка под ООП ядро.
>Господи, ну ПОЧЕМУ пишущий на PHP народ не в состоянии прицепить НОРМАЛЬНЫЙ движок шаблонов?
В данном конкретном примере показан тот факт, что пхп сам по себе является очень даже неплохим шаблонизатором. Вынесите логику за пределы шаблона, оставьте ему только вывод (как в приведенном примере), включите банально буферизацию и будет вам щастье.
>Фанаты XSLT могут привести пример, как это сделать на XSL, это не намного сложнее.
я конечно пхп знаю очень мало, однако xsl довольно неплохо, и мне кажется что пхп для тогоже дизайнера гораздо легче освоить чем xsl+xslt+xpath. если проект сделан на пхп, то проще всего в хтмл использовать тотже пхп ибо шаблонизатор и есть. и это кстати нисколько непомешает отделить модель от представления.
Чистейшей воды ИМХО, но ZPT (zope page templayte) более чем достойный engine. если надо что-то простенкое - можно внутри html, если логика посложнее - можно снаружи генерить. Всё пишется внутри html тегов, есть прекрасный механизм слотов, имеются удобочитаемые понятные выражения (коих немного), и главное прост в освоении и логичен :)
Да, у нас целый отдел обезьян. Нам, обезьянам, сложно понять, как можно давать HTML-кодеру возможность править PHP код. Особенно -- учитывая отсутствие необходимости декларирования переменных.