Использование Шаблонов технологии, принцип и все ЗА и ПРОТИВ
 

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

1) И вот что мне во всем этом не нравится (например известный Smarty и еже с ним), сначала выполняется код на PHP, потом парсится шаблон, в него подставляются данные, а многие конструкции опять же переводятся в PHP и выполняются (если требуется конечно, например те же циклы) и только после этого все выводится...

Это же очень медленно, хотя и используются всякие методы вроде кеширования и прекомпиляции шаблонов...

2) Да и вообще, какая разница особенно, писать {CONTENT} или <?=$CONTENT?> ????

3) Отсюда у меня возникает вопрос (наверное это какраз от моего диллетантства в этом), какой смысл заменять конструкции PHP на какой-то абстрактный язык? Ведь дизайнер если не знает ни PHP ни язык шаблонов (кстати PHP один, а шаблонизаторов куча), дак какая разница что ему учить? и потом ведь чаще всего чтобы изменить дизайн страницы можно просто не трогать код PHP, а изменить только то что нужно по дизайну (при условии конечно что код страницы оптимизирован для этого смотри пункт 2)....

Итак главный вопрос: Стоит ли использовать специальные шаблонизаторы (или писать самому), если стоит то какие, на чем основанные, на каком принципе....

P.S. Просьба высказываться только посуществу, не нужно писать типа "ххххх использует - значит это круто", или просто "используй реги"... По возможности высказывайтесь более подробно и аргументировано.

Всем заранее спасибо.

Hubbitus
Лично я думал, что эти самые шаблоны нужны, чтобы облегчить жизнь верстальщику. Сделать как можно более привычным для его глаз синтаксис шаблона. человеку, который в глаза не видел PHP (имеется ввиду дизайнер, или верстальщик) будет не очень приятно разбираться в сложностях (с его точки зрения) php. Ему гораздо проще освоить новый язык разметки, тем более, похожий на HTML (это по пунктам 2 и 3).
С первым пунтком тоже согласен. На мой взгляд Smarty-подобные шаблоны слишком тяжелы, хотя и довольно функциональны.

Мой ответ -- если в вашей конторе есть дизайнер или верстальщик (то есть человек, который занимается внешним видом сайта), то шаблоны нужны.
Подходов несколько. Зависят от того, какие фунцкии ты хочешь иметь в своем шаблоне. самый минимум можно реализовать str_replace :)
для навороченных типа Smarty -- либо переводить код в php либо писать свой сканер и лезть в дебри синтаксических анализаторов (лично мне по душе больше второй вариант).

Это вы загнули батенька - PHP vs полтора десятка кодов

Программист и дизайнер(верстальщик) как-бы не одно и тоже - нефиг маляру околачиваться в моторном отсеке и бадяжить машинное масло своими белилами цинковыми. Даже если выдрессировать маляра писать <?=$CONTENT?>, кто будет отвечать за последствия, а главное - их исправлять, маляр или программист?

Скорее нет, если такой вопрос возникает. Если не оч нужно, так и нефиг (дословнo - лучшее враг хорошего)

Мое имхо на этот счет:
- для своих сайтов я, ясен пень, не буду пользовать шаблонизатор
- если прийдется работать с кодером или для кодера - бессмысленно требовать от него бегом учить php. Шаблоны
- если буду сдавать движок стороннему заказчику, я туда не то что шаблонизатор, он-лайновый wysiwyg прикручу. Чтоб тока в код не лазили

Твой пост напомнил - что-то такое-же уже читал на xpoint - http://xpoint.ru/archive/threads/78/15670.html

Ты не видишь разницы между дизайном и содержанием. Заказчик дизайн должен будет рисовать в твоем wysiwyg?

Вопервых для каждого сайта это может быть свой язык, черти что я могу написать для разных проектов... А во-вторых, возможно ему стоит объяснить просто что PHP это не так страшно, темболее что требуется-то в простейшем случае всего пяток конструкций элементарных знать...
Не совсем понял идею, синтаксический анализатор же всеравно что-то типа парсера, он выяснит какой алгоритм подразумевался под той или иной конструкцией абстрактного языка шаблонов, выполнить же его тоже кто-то должен...
Ну извините, ктоже просит учить весь PHP, достаточно того же десятка конструкций в общем случае... Кстати в Smarty, например их гораздо больше....
Никто и не говорит что в общем случае это одно и тоже, в этом-то и главная проблема! Только вот где это разграничение цехов? А если внтри двигателя механику при сборке нужно что-то покрасить???
А кто будет отвечать за последствия ошибок маляра в синтаксисе {CONTENT}? Странное сравнение...Тоесть требовать от него выучить язык шаблонов это нормально, а 5 конструкций PHP, которые он сможет применять и дальше - черезчур?
Как правильно заметил RaZEr, Вы путаете некоторые понятия, одно другому не мешает. (Я же могу написать шаблоны и для смены внешнего вида WYSIWYG-редактора!)

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

1 - в случае шаблонов ты выдаешь только детальку покрасить, но не доступ к коду (самому отвинтить и привинтить). Соответственно, с шаблонами у пользователя несравнимо меньше возможностей что-то чисто случайно испортить. Дизайнер, котор, выучив десяток конструкций, будет считать что он разбирается в том-же php - это страшная сила. Не дай ему повод :)

2 - вообще-то я имел в виду шаблоны плюс wysiwyg, чтоб по максимуму ограничить позывы лезть в код (и php и html), бо контентом будет заниматься даже не дизайнер

А если мне нужно покрасить винтовое соединение, ну чтоб гайка не отвинчивалась, знаете? Тоесть я не могу открутить, покрасить, а потом прикрутить...
Вот это я совсем не понимаю, с чего это вдруг? Тоесть пример:
Чем это интересно он защищеннее следующего?
(В main.php cобственно b будут инициализироваться все нужные переменные)
Совсем не аргумент. А в том же легендарном Smarty часто, когда не хватает его функциональности, используя тег {php}...{/php} пишешь на PHP, для этого дизайнеру не полезно ли будет знать немного? Или тут нужно уже звать программиста? И вообще есть ли тут четкая грань? И потом не кажется ли Вам всем, что введение подобного тега разрушает всю концепцию раздельного дизайна???
Для контента - да, WYSIWYG, но ведь не об этом речь же сейчас вообще!!!

Что-же тут непонятного? Даже в вашем примере вероятность что-то испортить значительно выше:
а) вы даете доступ к <?include ('main.php')?>, соотв даете доп возможность
б) вы увеличиваете объем кода на треть, соотв увеличиваете стат вероятность
Это есть объективные показатели, а аргументы против ссылаются на здравый смысл, уровень интеллекта, продвинутость дизайнера/верстальщика в кодинге, т.е. чисто субъективные факторы, котор собсно шаблоны и должны исключить насколь это возможно. Чтоб не искать грань меж пограммером и дизайнером (она объективно на разных уровнях для кажного случая), а задвинуть ея на более безопасную глубь. Это вообще-то 1 к 1 суть споров DOS/WIN, Perl/PHP

Насчет {php}...{/php} - это всего-то запасной вход для программера, не для дизайнера да еще 1 плюс к функциональности продукта. Он обязан быть в продукте уровня smarty

зачем каждый раз свой? один для всех.
естественно php. но уже сразу в результирующий html-код, без промежуточного "объектного-кода" PHP, как это делает тот же Smarty.
наверняка вкючение кода шаблона будет производится внутри некоторого метода/функции, а не наоборот, так что про объем кода -- это не аргумент против. скорее даже за. поскольку общий объем шаблонов + его обработчика будет меньше. и разница будет расти прямопропорционально "крутости" шаблонов

Вообще-то речь об объеме кода, к которому имеет доступ непрограммист в случае неиспользования шаблонов (см. приведенный Hubbitus пример). Не об общем объеме шаблоны + обработчик

это тоже спорный момент.
Мое личное мнение по поводу шаблонов -- они должны заниматься ТОЛЬКО представлением данных. большинство же существующих позволяют ИЗМЕНЯТЬ и СОЗДАВАТЬ новые данные. По-моему последнее не есть хорошо.

Что значит "даю доступ" любой человек в здравом уме сможет запомнить что 1 строчку каждого файла шаблонов трогать нельзя :p
Ну на треть увеличивается только в данном мизерном примере, для нормальной страницы в пару килобайт объем одна эта строчка увеличит объем на сотые доли процента - это не вероятность...

Остальные доводы трогать не буду, т.к. с объективными-то показателями не все в порядке...
Кстати совсем не понял аналогии с DOS/WIN, Perl/PHP.... :biggrin: Оригинально, Вы же утверждали что нефиг маляру к механику в цех заглядывать, а механику значит можно беспредел творить? :)
Тоесть дизайнеру достаточно выучить один всего язык шаблонов??? Может тогда кто-то мне подскажет какой? Что уже есть стандарт на это, или W3C что-то рекомендовал :) А пока дизайнер будет вынужден изучать каждый раз тот язык шаблонов, который в данной комманде разработчиков заложил в проект программист (только не нужно говорить что можно и договориться им вместе, общий же случай рассматриваем...)

Да, но вместе с кешированием Smarty, это дает выполнение PHP-кода в последующие проходы, а при данном подходе всегда будет отрабатывать анализатор сперва... помоему не самый оптимальный путь...

Вот получается в ходе спора и еще один вопрос появился глобальный: а что же ДОЛЖНЫ шаблоны и что нет?

P.S. Вопросы только появляются :) :)

Предполагается, что человек работает в устоявшемся коллективе или по крайней мере мало изменяющемся. у которого уже есть некоторые правила общения/взаимодействия.а анализатор + кеширование дает сразу "чистый" html.....

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

я не совсем понял, что ты имеешь ввиду. Я говорил о преимуществе использования анализатора и кеширования перед Smarty + кеширование. Хранится уже результат работы. для анализатора -- это уже готовый HTML текст. если ты говоришь о том, что шаблоны которые используют <?=..?> работают быстрее - то с этим никто не спорил.

вы здесь сильно отвлеклись от темы, пошли в какието дебри теории, когда жизнь куда проще ))
рассматриваем приведенные выше примеры и смотрим на их плюсы и минусы.
1. содержание main.php
2. содержание main.php
прошу прощения, если гдето ошибся :) но теперь перейдем к плюсам и минусам:

вся цель "раздельного питания" это обезопасить код, т.е. сделать ядро (которое вообще лучше закодировать ZE) и позволить пользователям делать максимум на остальном уровне, при этом чтоб уменьшить вероятность взлома. Хорошим примером этого является xNuke ( http://xnuke.info ).

берем возможность того, что стерли main.php. в первом варианте, в итоге мы увидим просто текст с {TITLE} и {CONTENT}, во втором же мы не увидим ничего или вообще получим ошибку. какой вариан лучше, решайте сами.

во втором варианте минусом можно посчитать излишнее создание переменных, в первом же варианте просто создается новый Markup Language.

думаю в этом направлении и стоит сранивать 2 эти примера.

p.s. в принципе, оба варианта создают разделение, просто разными методами. их оба можно сравнить с вариантом

Тоесть все остальное не важно, производительность например? Хотя наконец-то кто-то обозначил более или менее цель этого всего. :yees:
В готовом проекте можно просто отключить вывод сообщений об ошибках и в этом примере во втором варианте мы получим просто <title></title> а в первом еще и выведем информацию которая может помочь злоумышленникам во взломе, это уж если говорить о безопасности.
Ну если излишнее создание переменных минус, то можно сделать один массив... А вот о целесообразности создания нового Markup Language я и поднял вопрос, и на протяжении всего этого топика его пытаемся со всеми решить!!! :biggrin:
plohich я так и не понял твоего мнения по этому поводу, как делать "правильнее" и почему? Сравнивая эти варианты, к чему ты пришел, какой лучше (или может третий какой-то)?

склоняюсь больше к первому варианту. закодированное ядро, а для пользователя создается свой ML с которым (и в рамках которого) он и работает.

Не вижу, что мешает сделать откомпелировать ядро во втором варианте?

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

Теперь по поводу разделения труда.
Имеем цепочку "дизайнер -> верстальщик -> программист".
Как должна происходить работа?
Дизайнер отдает верстальщику скриншоты сайта, тот собирает шаблоны, программист пишет скрипты, которые будут собирать информацию для шаблонов. При этом верстальщик должен отдать программисту спецификации на шаблоны, как минимум, описание переменных, которые используются в шаблоне. А заставить писать кого-то спецификации очень сложно, особенно в неустоявшемся коллективе.

Я предпочитаю использовать синтаксис вида <?=$title?>, по нескольким причинам. Во-первых, так сложилось исторически. Во-вторых, они работают быстрее. В третьих, часто мне приходится самому писать шаблоны на основе HTML-кода, который мне дает верстальщик, и мне гораздо проще работать именно с таким синтаксисом.

Правда, в последнее время, все чаще смотрю в сторону связки XML/XSLT, в этой ветке такой подход еще не обсуждался. Система шаблонов XML/XSLT имеет следующие преимущества:
1) Нет проблемы переписать серверное приложение на другой язык, шаблоны менять не придется, практически во всех современных языках поддерживается работа с XML/XSLT.
2) Упрощается обмен информацией между верстальщиком и программистом. Верстальщик отдает программисту XSLT и DTD, согласно которому программис будет создавать XML-документ.
3) Используя XSLT можно легко менять формат выходного документа, от HTML и WML, до PDF, PS DVI и проч.

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

Мне досих пор тоже было удобнее писать типа <?=$title?>, но я наконец решил что нужно поразбираться в альтернативных схемах.

1) При правильном шаблоне итак не будет проблем переписать под другой язык, шаблон также не придется менять, не вижу здесь проблемы.
3) - это бесспорно огромный плюс.
А теперь о всей этой технологии в целом, впринципе она конечно неплоха, НО, во-первых XML код обычно на порядок больше места занимает по сравнению с другими способами. Во-вторых - поддержка XML/XSLT в разных языках может все-таки различаться. И в третьих - я понимаю конечно, что можно написать все, в т.ч. хранить данные в БД, а потом их конвертировать в промежуточную форму (XML например) но ведь это изврат помоему, да и долго. А хранить большие объемы данных в XML - тоже убийственно, поэтому это не может заменить БД в любом случае.
Мне кажется что третье наиболее существенное препятствие.

Я имел в виду, что придется переписывать и шаблонный движок. Само-собой, в этом случае шаблоны переписывать не придется.
Это верно, но во-первых можно поизвращаться, поудалять лишние пробелы и т.п. Для примера можно посмотреть формат файлов OpenOffice.
Во-вторых, XML можно рассматривать как участок PHP-кода, в котором происходит занесение переменных в шаблон (те самые assign()) и я не думаю, что такие два подхода будут сильно разнится в размерах, но остается открытым вопрос скорости, нужны бенчмарки.
В-третьих, собранный XML пожно использовать как один из уровней кеша. Это может быть удобно при реализации двух версий сайта HTTP и WML, когда наполнение одно и то же, но разнятся форматы отображения.
XML/XSLT это уже признанный стандарт с четкими RFC и я не думаю, что различные реализации не поддерживают RFC. В ПХП есть возможность использовать libxml, libxslt, эти же библиотеки можно использовать и на перле и на си, думаю, есть и возможность прикрутить ее к asp и иже с ними, хотя в нем есть своя реализация xml.
Генерация XML не займет времени дольше, чем генерация HTML со вставками вида <?=title?>. Возможно, получится генерацию ускорить за функций для работы с DOM XML, но опять же нужны тесты. Так что, с определенной точки зрания, генерация HTML и генерация XML одно и то же, разве что структура XML будет проще, так как нет необходимости вставлять теги форматирования, следить за структурой таблиц и проч.
Но добавляется еще один этап при генерации шаблона - преобразование XML->HTML с помощью XSLT, так что использование XML для реализации шаблонов будет чуть медленнее, чем прямая генерация HTML. С другой стороны имеем ускорение разработки, за счет упрощения взаимной работы верстальщика и программиста и упрощается поддержка проекта, так как шаблонизатор стандартный (гораздо распространеннее FastTemplate, Smarty и проч.)

Шаблонный движок переписать конечно придется, в этом неоспоримое преимущество стандартизированного XML.
Насколько Вам известно, OpenOffice хранит свои файлы в XML, сжимая их архиватором, конкретно GunZip'ом. Это же неприемлемо для Веб-сайта с нормальной посещаемостью (даже если выделенный сервер не вижу причин так понапрасну расходовать процессорное время).
Когда требуется такой уровень кеша, который по структуре подходил бы к разным представлениям - ничего не могу сказать - не знаю, не сталкивался, но для каждого конкретного случая в отдельности можно реализовать куда более оптимальный способ представления кеша.
:biggrin: HTML, DOM и CSS уже сколько лет стандарты, а поддержку одинаковую у разных браузеров все также ждут миллионы программистов/верстальщиков по всему миру :biggrin: Что касается XML - я НЕ сравнивал, и НЕ знаю о различиях реализации, но подозреваю что и тут камней будет море.
Может кто-то поделиться своим опытом в данном вопросе?

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

Если быть точным, то в архиве несколько файлов XML, и не только они. Я имел в виду организуцию XML-фалов (в них все лишние пробельные символы удалены) но не достижение сверхмалого размера за счет архивирования.
Согласен, но такая функциональность скорее следствие, а не первопричина выбора технологии.
Основная проблема несовместимости браузеров не в том, что они не поддерживают стандарты (стандарты в каждом браузере реализованы полностью), а в том, что каждый браузер по своему воспринимает отхождения от стандартов, хотя это мое ИМХО.
Именно поэтому я и упомянул о библиотеках libxml и libxslt.
Именно так, при условии, что потери производительности не будут колоссальными ;) . Ведь все с удовольствием пользуются фабриками классов, не смотря на то, что они отрабатывают в разы медленнее, чем прямое создание объектов. Да и, как видно из ветки, люди согласны жертвовать производительностью при выборе механизма шаблонизации, разница лишь в том, что шаблонизация с использованием XML, более общее решение, чем большинство шаблонных движков.

Я и написал файлЫ, но дело не в этом, удаление пробелов - это лишь капля в море, проблема "большого объема" остается весьма насущной при интенсивном использовании.

Про функциональность в целом и совместимость такого подхода с использованием XML, я и не спорю. Меня инетерсуют также и другие факторы, и насколько "плюсы" перекрывают "минусы"!
Ой, вот тут Вы не правы!!! Лучше всех стандарты поддерживает Мозилла (моя личная оценка процентов на 90-95), опера достаточно неплохо их поддерживает но далеко не полностью, а вот с ИЕ, если Вы пробовали хоть что-то сделать по стандартам - начинается полный разброд!!!!! (Только умоляю всех, давайте не будем здесь обсуждать конкретно браузеры и их совместимость, ведь всем прекрасно известно что, например DOM2, ни у одного браузера не реализован в полном объеме :) )
Я не заметил в данной ветке всеобщего одобрения такой "жертвы". Всем же хочется найти эту золотую середину между жертвами и полученным преимуществом. Причем эти преимущества для каждого свои, а многие подразделяют еще и проекты, для которых приемлемо то или иное решение.

P.S. Наконец я осознал необходимость использовать шаблоноподобные подходы, только досих пор не могу понять на чем и как строить наиболее оптимальное решение.

вот в перле есть пара удобных шаблонных движков, HTML::Template
и template-toolkit.org. Я приспособился на втором генерить код в cgi CMS,
в который потом вставляется php :) Работает удобно :)

Шаблонных движков куча, и не про них вообще речь идет, а о идеологии и принципе построения.

А генерить на Перле код, в который потом вставлять ПХП - IMHO, изврат.

Проблема становится насущной только при наличии фактов, подтверждающих, что увеличение лишнего объема существенно повлияет на производительность. Да и отношение объема тегов к объему полезного контента, в общем случае, будет невелико.
Как я и писал в своем первом посте:
;)
Я же предупреждал, что это - мое ИМХО :)
Разве факт того, что человек использует шаблонный движок, не есть его согласие на "жертву"? ;)
Подведем итог.
Предложенные технологии:
1) Синтаксис ПХП.
- плюсы - быстрый не требуется переучиваться, большая функциональность и поддержка всех возможностей ПХП;
- минусы - нечеткое разделение кода и дизайна, слабая переносимость шаблонов (при реализации проекта на другом языке, шаблоны придется переделать).
2) Стандартные шаблонизаторы (Smarty, FastTemplate)
- плюсы - более сильное разделение дизайна и кода;
- минусы - не так быстры, как синтаксис ПХП, при переносе проекта необходимо будет кроме основного кода переносить и шаблонный движок.
3) XML/XSLT
- плюсы - полное разделение дизайна и кода, хорошая переносимость (работа с XML/XSLT реализована в большинстве современных языков);
- минусы - неясен вопрос производительности (по крайней мере для меня), вводится промежуточный способ хранения данных (XML).

Если у кого что есть добавить, прошу высказываться, только без постов вида "... рулит, все остальное %#@$" :)

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

Итог Вы подвели очень неплохо, действительно хотелось бы собрать побольше статистики, основанной на опыте..

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

Кстати, не учел еще один вариант:
4) Шаблон с произвольным синтаксисом конвертируется в шаблон с синтаксисом ПХП

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

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

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

Можно, конечно, после компиляции шаблонов их еще и через ZendEncoder прогнать, но какая-то длинная цепочка получается, да и Zend Encoder не совсем бесплатная программка, к тому же требует наличие ZendOptimizer'а на сервере.

Очень надуманный пример. Программер глупый чтоли????

Глупый, невнимательный, ленивый можно назвать как угодно, но, учитывая, сколько раз я сталкивался с ситуацией, когда перед экспериментами с базой данных не делали ее дамп и теряли большую часть информации, можно предположить что программер просто поленится сделать все по уму.
Риск возникновения ситуации остается и приходится вспоминать Закон Мерфи: "Если существует вероятность допустить ошибку в настройке прибора, техник ее обязательно допустит". В нашем случае руками поправит шаблон.

А какой резон делать преобразование my_template->php_template в час икс? Это обычно делается по нажатии кнопки "сохранить шаблон" в веб-интерфейсе системы. И кэша в данной ситуации просто нет.

имхо, для php4 в любом случае нужно использовать HTML, по причине того, что XML/XSLT там поддерживается экспериментально, и не все функции удовлетворяют стандартам DOM. к тому же это банально неудобно(именно в php4).

последний месяц использую: KTemplate вместе с php4.

плюсы:
+очень легкий и небольшой класс
+возможность делать шаблон в одном файле, т.е. допустим нужно "раскрасить html"(вполне стандартная задача). KTemplate позволяет задать возможные куски в одном файле. На php остается только распарсить и соединить нужные блоки.
+полное отделение кода от представления

в php5 появились действительно полезные возможности, например simpleXML, с которым работать одно удовольствие. тут уже можно серьезно заняться решением: XML|XSLT. Пример недавно был приведен в этмо форуме.

Привет.


1. Вообе-то поставленный вопрос (об использовании шаблонизаторов) становится неактуальным если верстальщик (верстальщики) и программист (программисты), работающие над проектом, очень хорошо знают свое дело. В этом случае хотя и получается изобретение велосипеда, но этот велосипед ездит быстро и не ломается.
2. К тому же, че универсальнее инструмент (Smarty, например) для работы с другими инструментами (php+mysql+html+css+js...), тем больше вероятность нестабильной работы объекта (web-приложение), который с помощью этих инструментов создан. И, да простят меня модераторы за маленький флуд, если Вы используете все эти инструменты и у Вас все работает быстро и корректно - значит Вы постигли Дао web-разработки и к Вам применим пункт 1. :biggrin:

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

Мое субъективное мнение. :rolleyes:

Интересно, почему это он становится неактульным? Вопрос разграничения работы и зоны ответственности встает только острее, если работают профессионалы...

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

почитал я эту ветку и вот чего подумал:
можно же написать прогу (хоть на дельфях, хоть на том же php) которая будет менять {Сontent} в шаблоне на <?=$Content?> и записывать полученный файл на сервак, причем ни программер, ни верстальщик не будут видеть/редактировать полученный файл. Получается этакий компромис.

ReapeR
Этот вариант рассматривался выше и отмечалась некотороя сложность с поддержанием соответствия локальный файл -> шаблон и отсутствие (или почти отсутствие) возможности запретить прямое редактирование откомпилированного шаблона.

сейчас буду первый раз использовать систему xml+xslt+php5+база данных
система такая:

есть бд(данные)

есть формат данных(в xml)+шаблон(ы) в xslt.

при редактировании базы данные меняются:

1. в базе.
2. пересоздается xml-файл.

при запросе всегда выдается: xml+xslt => html.

такая схема очень хорошо подходит для страниц, которые не часто редактируются(каталог, публикации и т.д.).