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

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

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

Ну вобщем то я об этом и говорю. Так получается мне просто нужно запрограммировать шаблон? А почему инклуды не пойдут? Я рассматривал популярные движки. Там вроде DIV'ная верстка и вставленные туда модули.

И еще вопрос что означает использовать API функции на странице? Если говорить долго можно просто ссылку дать. Если не трудно.

<!--QuoteBegin--><div class='quotetop'>QUOTE</div><div class='quotemain'><!--QuoteEBegin-->А почему инклуды не пойдут?<!--QuoteEnd--></div><!--QuoteEEnd--><br>Надо запустить модуль, чтобы он обработал данные, потом забрать у него обработанные данные и уже применять в своих шаблонах.<br><br>пример,<br>шаблоны типа:<br>

 
<div>
{$my_text}
</div>
 

{$my_text} заменяем на передаваемую переменную $my_text из модуля. и так далее

http://smarty.php.net полезен

Ну, есть модуль, допустим, новостей. И есть у него интерфейс — функция вывода списка новостей, ленты новостей, полного текста новости и т.п. На своей странице эти функции и вызываешь там, где надо.

Т. е. то, что предлагает md5


Это и является использованием API функций.

В принципе мы докопались до соли. Это мне и непонятно. Непонятно как вообще работает механизм между дивами. Мне что в моем модуле (Новости например) следует завести какую то функцию при обьявлени которой на главной странице будет происходить вывод результатов?

эта функция должна найти допустим последние три новости, сформировать массив и передать в шаблонизатор, который уже циклом и построит блок из трёх новостей (допустим)..<br><br>в функции:<br><br>

 
$array = array();
$psql = $mysql -> Query ("SELECT `id`, `date`, `content`
                          FROM `".$config -> table['news']."`
                          ORDER BY `id` DESC
                          LIMIT 3")
                          or die ($mysql -> Error("",__FILE__,__LINE__,mysql_error()));
while ($prow = $mysql -> FetchAssoc($psql))
{
  array_push($array, $prow);
}
 
$smarty -> assign('news_array', $array); //передаём шаблонизатору сформированный массив с 3 новостями
 

в smarty:

 
{foreach key=key item=n from=$news_array}
{$n.date} : {$n.title}
 
{$n.content}
 
 
 
{/foreach}
 

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

Лично я использую самописный шаблонизатор.
Он состоит из парсера и библиотеки модулей.
Парсер, библиотека модулей и сами модули - являются обьектами.

Структура шаблона примерно такова:
(названия условны)
main.tpl

...

{container}BODY{/container}

...


news.main.tpl
{BODY}
...
{macro}name=doRegistrationForm;default_value=что-то там{/macro}
{include}path=external_url{/include}
{mod_rewrite_url}/news/2003/12/23/{/mod_rewrite_url}
...
{/BODY}

Каждый Псевдо-тэг (С) ;) имеет реализацию класса-обработчика, который является наследником, скажем, класса lib_Modules и, соответственно, включает в себя методы родителя (пусть это будет метод doExecute($data) ).
$data - это все, что находится внутри фигурных скобок (инициализаторы тэга).
Каждый класс, реализующий обработку какого-либо тэга имеет свою реализацию метода, который разбирает входные данные.
То есть я могу для одного тэга определить разборщик входных данных, который игнорирует наличие Псевдо-тэгов, а для другого после разбора параметров, скажем для параметра text создавать экземпляр парсера и передавать туда значение text. Затем я получу "отпарсеренное" значение text и буду с ним работать.

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

фи... смарти :P
я тоже использую свой шаблонизатор с разаделением на блоки
смарти не удовлетворяет идеологии шаблонизатора

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

Вот почему я когда делаю шаблонизатор то не встраиваю поддержку фукций и тд

Не понял. То есть предлагаешь оформлять все шаблоны в виде:

Вот здесь я бы поспорил, что это оптимальный вариант...

AlexBB, ну поспорь. Только мотивированно и аргументировано.

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

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

max_ru Спасибо! Я об этом и говорю. Да конечно процес усвояимости твоей информации еще далеко не закончился, но думаю это поможет.

Ну например, дизанер изобразил такое:
<table >
<tr >
<td ></td >
<td ></td >
<td ></td >
</tr >
<tr >
<td >Название 1</td >
<td >Название 2</td >
<td >Название 3</td >
</tr >
<tr >
<td ></td >
<td ></td >
<td ></td >
</tr >
<tr >
<td >Название 4</td >
<td >Название 5</td >
<td >Название 6</td >
</tr >
</table >

Т.е. логотип компании, под ним подпись. В три столбца. Название компаний и их логотипы у нас находятся, разумеется, в массиве, который пришел из CMS системы, базы данных и.т.п и.т.д.

$companies = Array(
Array('logo' => 'logo1.gif', 'name' => 'Название 1'),
Array('logo' => 'logo2.gif', 'name' => 'Название 2'),
Array('logo' => 'logo3.gif', 'name' => 'Название 3'),
Array('logo' => 'logo4.gif', 'name' => 'Название 4'),
Array('logo' => 'logo5.gif', 'name' => 'Название 5'),
);

Теперь представим php код, который это отбражает. Лень его писать ... желающие могут попробовать. Но как минимум он будет характеризоваться следующим:
- В силу того, что информация об одной и той же компании находится в разных блоках <tr > у нас будет два цикла по одному и тому же.
- В коде будут условия на предемет проверки, когда окрывать когда закрывать <tr >.

Ну что возьметесь написать красивый и хорошо читаемый php, который любой верстальщик поймет?

Теперь берем шаблонный движок, я обычно использую XTemplate. Шпблон имеет весьма читаемый вид:


<table >


<tr >

<td ></td >

</tr >



<tr >

<td >{company.name}</td >

</tr >


</table >


В нем нет никаких циклов и ифовов. Только блоки имеющиее осмысленные названия и знакомый верстальщику вид. А теперь php код

include('xtemplate.class.php');

$xtpl = new XTemplate('table.tpl');
$i = 0;
foreach($companies as $value)
{
$xtpl->assign('company', $value);
$xtpl->parse('all.line.logos.logo');
$xtpl->parse('all.line.names.name');
if (++$i == 3)
{
$xtpl->parse('all.line.logos');
$xtpl->parse('all.line.names');
$xtpl->parse('all.line');
$i = 0;
}
}
if ($i < 3) // На случай неполной линии>{
$xtpl->parse('all.line.logos');
$xtpl->parse('all.line.names');
$xtpl->parse('all.line');
}
$xtpl->parse('all');
echo $xtpl->text('all');

Цикл перебирающий все компании один. Теперь представьте, что извращенец-дизайнер еще и где-нибудь в другом месте решил вывести все названия ... дублирующее меню типа. Еще один цикл? Вовсе нет ... всего лишь еще один $xtpl->parse и ВСЕ!
И наконец мы получили хорошо читаемый код ... в нем логика отделена от представления и нет никаких

if () echo '<tr >' else echo '</tr >';

Таких приеров можно привести кучу. Но суть одна:
1. Шаблон позволяет генерить HTML не в порядке ИСПОЛНЕНИЯ PHP СКРИПТА т.е. сверху вниз, а в порядке получения данных.
2. Шаблон все-таки лучше, чем чистый php разграничивает данные и представления. Т.е. имеем читаемый шаблон.
3. Шаблон делает более читаемым php код, избавляя его от конструкций налагаемых дизайном.

В общем вот. Почти статья получилась. :) Осталось добавить громоздкий скрипт без шаблонов.

Позволю не согласиться. Вернее согласиться не со всем. Оттого что тут присутствуют html-тэги, это не означает, что он имеет понятный вид. Скорее эти знакомые тэги только будут сбивать верстальщика с толку. На самом деле данный шаблон записан с помощью достаточно сложного метаязыка. И далеко не все верстальщики смогут разрулить конкретную таблицу изначального макета с конкретным количеством строк и столбцов в данный абстрактный шаблон. Не потому что верстальщики тупые, а потому что это тр*цензура*ет абстрактного мышления в области несколько отличающейся от привычной им.

Опять-таки шаблоны могут отличаться по своей структуре:
1. Такие меташаблоны, как приведенный здесь. В данном случае точного ответа на все случаи жизни, что лучше — данный метаязык или голый php — не будет.
2. Шаблоны с последовательным заменением макросов. Т.е. в шаблон вставляются последовательности, типа, {TITLE} и т.п. и они заменяются при формировании страницы на соответствующий текст.
Во втором случае единственное, чем такой шаблон может быть предпочтительнее php-вставок, это уже указанное:

Однако при грамотной проработке структуры здесь нет никаких проблем. На самом деле, что мы имеем при ситуации с самопальными шаблонами:
1. Есть файл php-сценария.
2. Есть файл шаблона написанный в придуманном программистом формате.
При запросе страницы, запускается сценарий (1), выполняет, какие-то действия, получает какие-то данные, после чего считывает файл (2) и обрабатывает его на основании уже имеющихся данных. Здорово.
Только что нам мешает сделать файл (2) php-сценарием? Т.е. (1) отрабатывает, получает данные и вызывает (2), который уже на основании уже имеющихся на этот момент данных выводит разметку страницы.


if else будут всегда. И у тебя они есть. А в самой реализации XTemplate их вообще немерянно. Только они скрыты от верстальщика. Кто же нам мешает скрыть их и в этом случае? Верстальщику совершенно не обязательно вписывать кучу кода в шаблон. Ему достаточно вставить . Можно еще параметры у функции сделать — количество строк и количество столбцов.

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

PS. Вобщем если мои слова
были поняты, как призыв делать все на голом php, как делают все начинающие, то, конечно, это не дело. Несомненно нужен какой-то мостик между программистами и менее посвященными в это дело. Другое дело, что вместо того, чтобы изобретать фиг знает что, можно просто поближе подружиться с пыхом.

vasa_c - может я немного не по теме выскажусь, но просто кодию тока на шаблонах(хотя недавно) - поэтому очень охота про них сказать высказаться=)))(Неприемлю ни строки html+php в одном файле).
По - моему глубокий смысл шаблона с том ,что он позволяет отделить логику приложения на php от непосредственной реализации вывода. т.е. это уже ООП программирование в каком-то смысле.А ООП это уже совсем другой уровень - это то, что по большому счету отличает любителя от професионального прогера.
Допустим если ты для примеру возьмешься кодить какое-то сетевое приложение на C++ и ,не дай бог, смешаешь там функции/классы передачи данных и логику, то после этого есть только один вариант - начать все сначала.И здесь все также, только менее заметно т.к. php на многое смотрит сквозь пальцы и вообще там нет очень серьезных таких приложений.Я по крайней мерее их не еще не встречал.Максимум ну 10-20 тыс. строк. - а это конечно можно сделать и на фунцкционале и без ооп.
Вообще глобальная проблема с которой я пока встречался на php (на дельфе кстати такая же есть).Все php кодеры которых я лично знаю (человек 5-6) как то плохо приемлют классы - ну и шаблоны.И вообще ооп.Как так вообще можно писать?
И кстати я научил нашего верстальшика шаблонному синтаксису. Я только потом в его заготовки уже синтаксис движка встраиваю и все.Очень удобно.Весь html код на нем.Я тока за логику отвечаю.
Вообще хочу сделать такое обращение ко всем php кодерам: народ пишите все только о.о.п. и пользуйтесь движками.Вы так сильно облегчите жизнь не тока себе ну и другим людям, которые будут после вас работать с вашим кодом =))

1. ООП это всего лишь методология и ничего больше. Программист должен уметь использовать, как ООП, так и не ООП. И главное, он должен уметь использовать, то, что нужно в конкретный момент. Этот самый "ООП" стал каким-то волшебным словом, на которое все ведутся. Видел людей, которые простые утилиты на ООП делали. Вот мы сделали на ООП, мы крутые. Правда прога ничего нового не делает, а делает, то что делала и раньше, только в медленее и размер у нее впятеро больше, но на ООП. Мочить таких.
Для больших проектов, особенно тр*цензура*ющих возможности расширения, ООП несомненно предпочтительнее функционального подхода. Правда, кроме ООП есть еще множество всячески "ориентированных" подходов — аспектно-ориентированное и т.д. Даже тот ООП, который все знают (с классами), это не весь ООП, а всего лишь одно его направление (основанное на классах), кроме него есть еще основанное на прототипах и т.д.

2. Абсолютно не понял связи между ООП и шаблонами.

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

Меняй свое мнение.


Я где-то был против шаблонов?

Ну кажется, что тебе больше функционал и модульный подход к пхп по душе =).
Про применение о.о.п. я серьезно.Сейчас вот контоллер надо будет программить если повезет - юзать буду ICC AVR с C - там стандарт какой - то не очень мне понятный - есть короче тока struct, а class - нет.Ну даже и при таких возможностях можно со строны а.о.п. там подойти и разбить опять же всю программу на работу непосредственно с портами(ввод вывод) и логику.Может еще и транспортный уровень понадобится=). а.о.п. там по-моему в самый раз.

Нет, мне по душе то, что в данной ситуации лучше. В проектах с разветвленной структурой мне по душе ООП. А почему такое презрение к "модульному подходу". Разве ООП это не дальнейшее развитие этого самого модульного подхода?

Да после одной проги это началось=).там руки просто поотрывать кодерам.3 тыс кода - непонятно ни одной строки.Если бы был раздел, где можно выложить самый корявый код так вот это 100% первое место.Ну или второе.Короче говоря призовое=).
Также я одно время работал в компании где как бы был тока о.о.п. подход к программированию - ну и мне понравилось так писать.Я тоже раньше функциями писал - переучили =).
Единственного "непереучившегося" функциональщика с позором выгнали - он просто гнул свою линию упорно - ну и у него ничего толком не вышло.Короче убил проект. Писал все одной функцией.Была у него такая отмаза: "Как будет работать - переведу на классы".Но как и следовало ожидать, с функциональным подхом он просто не смог отладить все ошибки и банально не дошел до момента когда у него все заработало.Если бы писал классами, так хоть бы часть его кода можно было заюзать потом.А так все в топку пошло. Такая вот грустная история.
Можно и функциями хорошо писать - не спорю, даже ,может, иногда и нужно, но после таких примеров я для себя выбрал о.о.п.
А вообще ,конечно, много есть разных проблем даже не связанных с подходом к программированию - глупый менеджмент, плохие напарники, тупые головы и кривые руки(как свои так и чужие),гашеные оффисы ну и т.д.Тут уж ты хоть функциональщик, хоть ооп-шник, хоть то и другое - ничего не поможет. =) Чисто мое мнение, хотя может и не очень точно в тему.

vasa_c , сорри за задержку, если не возражаете продолжим обсуждение: "Шаблоны на PHP - хорошо или плохо?" :)


Действительно, шаблон написан с помощью метаязыка и это реальная нагрузка на неокрепшие мозги верстальщика. Но, ИМХО, он все же имеет более понятный вид, чем конструкции на чистом php, по следующим причинам:
- Вместо обширного разнообразия конструцкций PHP - while, for, foreach он практически имеет одну единственную До верстальщика надо донести одну мысль - содержимое этих блоков способно тиражироваться.
- При удалении всех конструкций метаязыка мы имеем понятный html. Так сказать, предельный случай - таблицу из одного столбца и одной строки. Это интуитивно более понятно, чем смесь php+html.
- Сохраняется валидная структура html - открывающему тегу всегда соответствует закрывающему.


О да, согласен! Более того - практически все не смогут. Так что изначально такой шаблон должен писать программер. Но зато потом, верстальщик сможет разукрашивать эту таблицу сколь угодно долго, не завися уже от программера. 90% задача оформления и переоформления он решит самостоятельно.


Здесь я не до конца уловил мысль. А как во втором случае будет выглядеть шаблон, где блоки должны тиражироваться?


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


Гм ... я не сказал, что шаблоны позволят обойтись без if else. Я как раз именно и сказал то, что они отчуждены от html кода. Т.е. именно скрыты от верстальщика. Еще раз предлагаю, попробовать написать php шаблон для моего примера, чтоб они были скрыты. Если это получится - сниму шляпу. :)


А вот тут категорически не согласен. Забить нельзя никогда, ибо это ставит крест на всей идеи шаблонизации. Эта таблица может иметь черт знает какую структуру по сложности. В каждой ячейке еще 100 тегов может быть. И мы не знаем, когда взбредет в голову ее редизайнить и как.


А какая разница отдельный шаблон или все внутри общего шаблона? Что это меняет в делеме: "PHP или Макроязык"? Разделение шаблонов на части должно быть логическим, основанным на их сущности, а не исходить из того как нам удобнее програмить.


По большому счету да. Но как это сделать красиво без метаязыка? Могу только еще раз предложить попробовать.


Честно говоря, я так их и понял. Даже засомневался, поэтому предварительно переспросил:


И вроде, как получил утвердительный ответ.
А вообще, спасибо за подробный разбор моего примера и дискуссию

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

Может время будет еще пофлужу на эту тему )
А остальной контингент, что-то дискутировать на абстрактные темы особенно не любит )

vasa_c,
зато с удовольствием читает. :)

Просто у других пользователей не тот уровень программирования. Я сам неожидал что моя тема перерастет в философско-программерскую дискуссию.

По рассуждать в принципе можно. Незнаю может обывательское мнение даст новую пищу для размышления гуру :)

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

Однако самый большой минус этой технологии в том, что инфы об этом практически нет. Единственное что я нашел в сети достойного на эту тему это парсер от студии dezign.ru. Есть еще Smarty которую советовал мне md5 но с парсером гораздо легче работать. У него хорошие мануалы паказывающие не только как работать с ним но и описываются конкретные примеры.

Да и вообще весь смысл программирования сводится к готовому продукту. Можно долго подвергать муху радиации и сделать из нее слона, но кидаться на говно она не перестанет. В 99% случаев заказчику неинтересно как делается его заказ. Ему важно чтобы продукт хорошо работал и был удобен в использовании. Поэтому нужно думать ни как "попонтовее" завернуть код, или сделать его удобным для себя. Ведь существуют какието правила хорошего тона в программировании. Надо думать и о собратьях программистах которые возможно будут дорабатывать код. Ведь возможно и вы окажитесь среди тех кто дорабатывает чужой код.

Товарисчи! Единственная штука, которая РЕАЛЬНО характеризует ООП - это ПОДДЕРЖИВАЕМОСТЬ программ!
К примеру прогу на асме невозможно (неудобно) поддерживать при 2-3к строк кода.
Прогу на С - при 10к кода.
Прогу на С++ - при намного больше чем 100 миллионов строк кода.
lenich, 10-20к строк говоришь? =) Мой двиг, написанный на 60% занимает примерно 500 килобайт чистого текста (без шаблонов). Если бы не ООП, я бы уже раз двести запутался в функциях и модулях.
А когда я знаю, что модуль всегда возвращает переменные в ТАКОМ-ТО формате, а принимает функцией $Obj->Execute($data=false), мне уже как-то наплевать на внутреннее строение конкретного модуля и уж тем более наплевать на то как он работает. Собственно и это тоже главный плюс ООП.
Что же касается скорости работы...Да медленнее, но я приведу пример, который, наверное, заставит вас задуматься, а важны ли здесь те самые доли секунды, которые теряются из-за применения ООП?
Есть движок, который основан на шаблонизаторе и модуле подключения модулей-макросов. Шаблонизатор работает с помощью строковых функций. Вы думаете, шаблонизатор станет основным тормозящим фактором? Нет! Обработка шаблона страницы, например как эта, занимает около 0.01 секунды! Обработка этой же страницы без шаблонизатора 0.005 секунды! Как же не тормозит? В целых 2 раза - скажете Вы, не обращая внимания на АБСОЛЮТНЫЕ значения времени, затраченного на обработку страницы. Какая разница - за 0.005 секунды или за 0.01 обработалась страница, если данные, сгенерированные скриптом будут передаваться БОЛЕЕ СЕКУНДЫ!
Таким образом ООП не так сильно тормозит обработку скрипта, как многим хотелось бы =)
Что же может РЕАЛЬНО затормозить выдачу данных скриптом? Кто главный враг скорости работы?
Ответ 1 - БАЗА ДАННЫХ. На ответ базы данных при неоптимальных запросах или случайной (мгновенной) загрузке сервера на получение ответа от базы данных уходит порой более 10 секунд! Сравните 0.01 и 10 секунд!
Размещение базы данных на отдельном сервере (между прочим, абсолютно правильное решение для виртуального хостинга) еще больше усугубляет задержки при обращении к БД!

Вот собственно пока весь поток сознания =)

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

В общем рекомендую всем почитать статью об ООП из PHP Inside#18 phpinside.ru, если не ошибаюсь.

Средства парсинга шаблонизатор должен содержать в самую последнюю очередь. По моему заменять операторы вывода какими-то псевдотегами- полный абсурд. Зачем надстраивать над PHP ещё какой-то макроязык?! Задача шаблонизатора- компоновка страницы из указанных шаблонов по указанному сценарию. Фишка в максимальном расширении возможностей редизайна- сменил одну страничку, и не узнал весь сайт. К оформлению PHP вообще логичнее привлекать по минимуму- ведь есть же CSS. Последние, кстати, стандартизированны, в отличие от десятков шаблонизаторов. Ну ведь тупо же вместо СТАНДАРТНЫХ операторов вывода помещать муру на каком-то моноголо-китайском синтаксисе, когда с С-синтаксисом работают уже около четверти века!!! Просто надо писать код не криво, следовать тому же MVC. А задача шаблонизатора- реализация идеи динамической компоновки страниц(со всеми ПРИЧИНАМИ, приведшими к этой мысли), а не возня с "улучшением читабельности для дизайнера". Если код от страницы можно было бы отделить на 100% без потерь в других областях, так это ещё на Perl сделали бы. А для дизайнера головная боль не якобы непонятные и незнакомые конструкции PHP, а кривой "шаблонизатор", который наперевес с очередным доморощенным "эргономичным" "дизайнерским" синтаксисом заставляет забыть HTML и выучить ещё одну его кривую вариацию. А сменив работу с ужасом обнаружить, что на новом месте "идеальный" стнтаксис не признают. И опять всё сначала... Упростили жизнь, ничего не скажешь. Отхождения от стандартов Web-разработки должны быть минимальными. Будьте проще- и коллеги Вас поймут!

Если уж говорим об оформлении — при наборе сообщения желательно пользоваться энтером, получившееся гораздо легче усваивается.


Имхо здесь путаются 2 разные вещи:
1. Формирование, на основе общего набора данных, структуры документа с нужными данными (вот это поле шаблонизатора).
2. Визуальное представление означенной структуры документа (а вот здесь CSS)