Только что заметил этот топик. Актуальная и наболевшая темка
Все вы говорите правильно, но кое-где ошибаетесь.
PHP вставки:
Недостаткии у вставок PHP кода типа <?=$var?> я вижу такие:
1. Это дыра, т.к. дизайнер или еще кто-то кто не отвечает за PHP код имеет полный доступ ко всем переменным сайта, может неакуратно проверить работает ли exec("rm -rf *.*") и т.д.
2. Ээээ... да и нет больше недостатков в принципе. Вот только что по-идиотски выглядят шаблоны сайта. Верстальщика и правда может шугать, потому-что человека шугает все что он не понимает, такова природа.
А верстальщики понимающие PHP долго не живут (ну переквалифицируются в программеров).
Темплейты:
Темплейты типа FastTemplate, Smarty и пр. решают в принципе первую проблему. Но вторую просто вуалируют, при этом создавая каждый свой новый миниязык, который хоть и несложно понять, но непонятно зачем.
Но...
Не все темплейты одинаково полезны, некоторые добавляют еще и проблем верстальщикам, т.к. иногда миниязык темплейтов отнюдь не является валидный кодом или частично использует преимущества html, как например использует <!-- комментарии HTML --> для своих целей:
Код:
<!-- BEGIN list -->
<table>
<!-- BEGIN list_item -->
<tr>
<td>
{item_title}
</td>
</tr>
<!-- END list_item -->
</table>
<!-- END list -->
Комментарии не предназначены для этого! оставьте право (или возможность) использовать комментарии верстальщику! Довольно сложно например после таких вставок закоментировать весь этот приведенный блок, т.к. комментарии HTML не могут быть вложенными друг в друга. Кроме того комменты эти (по сути не комменты, а инструкции, отсутствие которых может привести к фатальной ошибке) могут быть запросто проигнорированы в визуальных редакторах HTML.
XML/XSL:
Вот тут не прозвучало ничего верного. Некоторые считают что XML должен заменить базу данных под MySQL, а кое-кто предлагает записывать данные в БД и в XML параллельно (кой нафиг толк в БД тогда?
). Но абстрагируйтесь от XML как от формата хранения. Система темплейтов основанная на XML использует (должна использовать) этот самый XML только для отображения, причем промежуточного, данных (не совсем корректно сказать следующее -- но все же для передачи нужных данных в XSL). Как это работает (вернее как должно работать):
Вся задача PHP сводится к тому чтобы создать переменную содержащую например следующий текст:
Код:
<page>
<title>Imho.ws / Варезник / Агнитум аутпост 2.0</title>
<user>denver</user>
<thread>
<page>1</page>
<lastpage>25</lastpage>
<post>
<user>User1</user>
<message>Hello everybody, need crack</message>
</post>
<post>
<user>denver</user>
<message>RTFM</message>
</post>
<post>
<user>User1</user>
<message>Hello everybody, need crack</message>
</post>
</thread>
</page>
Причем данная переменная содержит только тот текст (не считая тэгов, хотя они тоже важны) который будет в конце концов в конечном HTML. Не обязательно выводить все посты если будет показана лишь страница номер 1. Необязательно выводить все треды если будет показан только тред "Агнитум Аутпост 2.0" и т.п. Не нужно мегабайтных XML файлов. XML создается налету, а данные берутся из БД.
Итак, у нас есть уже XML (в памяти), применяем к нему файл showthread.xsl и отдаем получившийся HTML пользователю.
Возникает вопрос зачем генерировать XML (чтобы потом его еще и XSLем обрабатывать) если можно сразу в HTML пропарсить? А затем что у вас в ПХП станет на десяток меньше str_replace'ов (не надо парсить никаких переменных), на пару-тройку меньше preg_match'ей (нет смысла извлекать из темплейтов блоки <!-- BEGIN block1 --> ... <!-- END block1 --> чтобы их продублировать нужное количество раз). Это задача процессора XSLT. И (гипотетически) модуль XSLT будет конвертировать XML в HTML быстрее чем ваш PHP код со всеми str_replace'ами и preg_match'ами вместе взятыми. А кроме того:
Плюсы такого подхода:
1. Никакой зависимости от оформления. Т.к.:
а) неважно в каком месте XML (в начале или в конце) находится какая-то переменная или блок, XSLT выведет (или не выведет) его в том месте HTML в котором надо.
б) Больше никаких "двойных" блоков (или лишней переменной $bgcolor например) если надо сделать таблицу с зеброй. Зебру будет делать XSLT.
в) XSLT даже может создать навигацию страниц типа: Страница 2 из 25 (на первую) [1], [2]...[25] (на последнюю). Единственно что нужно это задать в XML что-то типа <thread page="2" lastpage="25"> ну или как угодно, главное чтобы валидно.
д) Верстальщик может менять XSL а программер XML одновременно, не боясь получить логических ошибок типа "нужный блок не найден" и т.п.
е) а также е) ж) з)... -- PHP код сводится к минимуму, т.к. все (буквально все) задачи связанные с отображением и дизайном переключаются на XSLT ("вставьте мне сюда серое, а тут белое, через одно" - вали к верстальшику, в коде PHP этого быть не должно. "Хочу чтобы каждая первая буква параграфов была картиночкой с прикольной буквочкой" - к верстальщику, "Здесь тоже мининавигацию вставить" - туда же). Задача PHP -- вывести только необходимые _реальные_ данные.
2. Скорость вывода XML + обработка его XSL (не забываем что это практически встроенная функция) теоретически больше чем парсинга переменных и блоков в HTML (не забываем о куче str_replace, preg_match).
3. Верстальщик получает безграничные возможности по оформлению данных, и вообще меньше бегает к программеру если нужно что-то приукрасить, удалить (реже добавить) пару блоков на нужных страницах и т.д. и т.п. все что связано с оформлением больше не беспокоит программера.
4. Никаких дырок и пр.
Минусы:
1. (первый и последний). Верстальщику придется знать XSLT (хоть и не шибко сложный, но энивэй) (хотя с другой стороны - если не XSL, так Smarty, который не понятно что за язык и непонятно с каким будущим).
2. (ан нет, не последний). HTML должен соответствовать XHTML, т.е.больше никаких незакрытых тэгов, никаких инвалидных закрытй типа <b><i></b></i> и т.п. Но это даже полезно будет.
ЗЫ. Кроме того. Не сегодня так завтра, когда все больше браузеров смогут обрабатывать XML + XSL сами (сегодня это только мозилла последних версий и IE начиная с 6.0) весь парсинг можно вообще перекинуть на сторону клиента -- отадавать сгенерированный XML (включаем в него также ссылку на XSL). Но это все будет только лет через 5, когда старые браузеры наконец исчезнут (блин, когда ж они все исчезнут).