Полное и грамотное разделение оформления и содержания, можно добиться только правильной организацией процесса разработки. И тут уже сугубо по барабану, какую технологию вы используйте – да хоть ручками вставляйте. Главное – чётко, по полочкам разделить обязанности всех участников процесса. Дизайнер рисует, на этом его круг обязанностей заканчивается окончательно и бесповоротно. Ведущий программист, проектирует бизнес логику, раздаёт задания программистам и координирует процесс производства продукта. Программист занимается реализацией заданной бизнес логики, подготавливает конечный продукт.

Цепочка получается простая: Вася - ведущий программист, придумал гостевую книгу, дал задание Пете программисту и Маше дизайнеру. Пете – реализовать предоставленные алгоритмы; Маше – нарисовать интерфейс. И Маша, и Петя сдают работу Васе. Вася принял макет Маши, передал этот макет Пете. С макетом Петя получил ещё и инструкции от Васи, в которых чётко расписано, что и как надо делать с макетом.

Оформление от Маши, движок от Пети, а содержимое от клиента (он же – конечный потребитель созданного блага). Вот это – полное и грамотное разделение оформления и содержания. Маше, Васе и потребителю до лампочки, что там использовал Петя: FastTemplate, Smarty, XML, HTML::Template или ещё какую технологию. Это заботы конкретно Пети. Хотя тут и забот-то нету – выбрал то, что тебе нравится, и всем предоставленным требованиям отвечает .

Не могу понять, почему вы до этого так долго идёте? Судя по тому, что тут было написано, ни одного крупного коммерческого проекта никто не писал. А если и писали, то организация этого проекта оставляет желать лучшего. Попробуйте свою точку зрения, положить на масштабы того-же Microsoft'a и представить, как бы ваша логика работала в их рамках. А там надо не 10 и 20 человек организовать… Вот уж кто Вильям Гейтс, так это прирождённый IT-менеджер.

А теперь в тему.

Технология шаблонизции данных, нужная и полезная вещь, которая позволяет не мешать Маше и Пете выполнять свои непосредственные обязанности и помочь менеджерам отделить мух от котлет. В свою очередь, заблуждения о том, что шаблонизатор A, хуже чем B, потому что, он не умеет делать … вообще безосновательны. Каждая система пишется с учётом определённых требований и не может быть использована для любого проекта. Только поэтому выбор этих самых шаблонизаторов такой широкий, ибо не каждому подходит A, потому что он …, … и …

Сегодня время Smarty и FastTemplate, завтра XML, послезавтра ещё чего-то, т.к. возможностей первых двух хватает на сегодняшний день. Мне например обе эти системы не подходят из-за их «навороченности». Никакой шаблон недолжен нести код. Мы помним, что этот самый шаблон рисовала Маша, а она ни php, ни perl даже в глаза не видела - У неё есть 8Mpx цифра, яблочный комбайн, ручки и хорошие способности к рисованию. А вот Петя, уже должен суметь без запускания пальцев в исходный макет (идеальный вариант) написать систему, которая этот конкретный макет будет использовать. Вот XSLT в полной мере позволяет решить проблему запуска ручек Петей в Машину работу, окончательно закрыв этот топик, а Smarty и FastTemplate заставляют Петю лазить по Машиной работе, вставляя туда шблонизаторскую разметку.

Я хочу сказать, что если ты используешь XML/XSLT ты должен обеспечить валидный XML источник, а в случае с шаблонизаторами вроде <?=$some?> я могу позволить себе писать такой HTML какой хочу. Хочу забуду закрыть <li>, хочу слеш не поставлю в img и т.д.
Почему же. В содержимом мы задаём логику документа => если тот же клиент имеет возможность вводить содержимое, то он и логику может задавать.
Т.е. если клиент написал в коде <img ...> то я должен его вырезать? А кому такой CSM нужен будет тогда...

RaZEr
Снова тебе RaZEr повторю, ты не обижайся, в XML ты можешь себе позволить любой HTML код какой захочешь!!1

Приехали. Нашел к чему придраться...
Хочешь вырезай а хочешь оставляй, дело то твое.

y13
Это глупый менеджер так поначалу всегда думает, ага... И точно точно, гляди, вот так же подчеркивает эти слова! :claps:
А потом:
Это он потом уже типа думает, ага... А может вообще не подумать, а Маша и Петя будут его вспоминать нехорошими словами, пока не сдадут проект.

Нет, брат y13, хреновый из тебя проектировщик и менеджер :biggrin:

Да не любой, далеко не любой. Ты думаешь я парсер эрроров мало видел?! Понимаешь все XML/XSLT парсеры хотят 100% валидный HTML т.е. - XHTML. А это проблема. И коды счетчиков и различные блоки страниц, которые клиенты хотят редактировать сами. И дубль два - они хотят редактировать не результирующий HTML, а исходное содержимое которое потом пройдет через парсер!

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

RaZEr
Может ты приведешь пример? А то я что-то не могу понять что за сайты такие проблемные ты там разрабатываешь.. Пример в студию.

Да просто всё. Есть CSM, есть визуал-редактор (window.design_mode). Последний из них имеет привычку генерировать не слишком валидный код (IE вариант), который тем не менее неплохо бы пропустить через XSLT. Хотя бы потому что простой тег <p> может быть в дизайне представлен красивым блоком с округлыми краями.

А теперь, если можно, по-русски и со смыслом. С доводами, с примерами, и чётким обоснованием собственной мысли. А то так, фикция сплошная.

P.S.
Глупый, не глупый, а деньги получает. Маша с Петей не грустят. Проекты вовремя уходят. Странно да? Надеюсь, без глупых намёков и поспешных выводов Вы сможете прожить? Иначе я тоже наделаю поспешных выводов и ретируюсь задом. Не вижу смысла спорить если у оппонента такой взгляд на мир. Ничего нового так и не узнаешь.

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

RaZEr
На твоем бы месте, весь код от этой HTMLArea на выходе обрабатывал бы автовалидатором (автоматом закрываем все тэги). Если ты считаешь что это тупо то что поделать -- ты хочешь и на... сесть и рыбку съесть :)
Я бы не стал думать об обработке пользовательского текста XSLем. Это слишком чревато, да и не нужно никому.
Я не видел ни одного сайта где такое реализовано, и вряд ли будет до выхода CSS3 (а в мозилле уже есть вон -moz-border-radius межпрочим, говно, а и то хорошо)

y13
Если я еще четче, еще понятнее, еще доходчивее, еще подробнее напишу чем я распинался страницей ранее, то меня поймет любой имбецил. Но я не люблю разъяснять имбецилам.

Именно этим я и занимаюсь - разбираюсь что же собственно требуется от шаблонов в общем случае, какие задачи и пути их решения. Как я уже говорил выше, я уже написал класс, типа этого FastTemplate, где реализовал основную функциональность необходимую мне на данный момент и постоянно помаленьку дописываю при возникновении новых задач... Как я всевремя подчеркиваю, меня интересуют больше основы и принципы реализации, а не сама реализация, а мне постоянно пихают куски кода, как-будто я просил написать мне на PHP строку замены переменных в тексте или что-то подобное!!!!Может все и не нужно, а основные какраз необходимо. В Смарти можно делать многое, но я же привел где-то выше пример что из него получается в таком случае... подозреваю на XSLT ничуть не понятнее (для дизайнера) и не проще получится код при написании нетривиального оформления...
Вот, и RaZEr очень прав сформулировав так задачу обсуждаемую здесь:не больше не меньше, пока мы даже не пришли ни к какой конкретной ("грамотной" или идеальной, если хотите) концепции разделения!!

Ага, а если исполнитель и дизайна и программирования логики и координирования проекта это один человек, то и говорить нечего :) Ты подумай банально, он реализовал на одном, подключили еще программиста (или просто подумай что потом кто-то править будет) - и он вынужден разбираться что наворотил Петя... Но это даже врядли главное, первый вопрос посути - как ему-то что-то выбрать и по каким критериям из доступных технологий?

Вооот, вот об этом я и говорил - дизайнер должен дизайнить (уж простите за каламбур). Ну и если ему сказать что на странице вместо "Вася" нужно писать скажем "{NAME}" то он это еще должен пережить, а если ему скажут что он должен написать еще и логику отображения, на какаом-либо языке (будь то XSLT или Smarty или другие) то это уже странное какое-то разделение. С другой стороны, если все это возложить на программиста, которому дают картинку лишь дизайна на входе (как я понимаю так чаще всего и бывает), то ему вообще проще расставить в HTML вставки типа <?=$var?> поместить это в БД, ну или в файлах сохранить и просто выводить в нужных местах - ничего быстрее этого не придумаешь уж точно - ноль обработки.Кстати незнаю как для тебя denver, но это крайне актуально на самом деле, ты видел какой код формируется в таком WYSIWYG редакторе? Там помоему сам Гейтс не сможет часто объяснить как это так вдруг так получается! А еще нужно учесть подобные прибпмбпсы для разных браузеров...

Hubbitus
Да, я видел что получается из HTMLArea особенно если в нее копипэйстить мсворд. Однако все проблемы не так актуальны если юзать:
В общем случае требуется:Т.е. общих случаев два. Второй это как раз то что тебе не нравится -- верстальщик занимающийся "программированием" вывода. Значит для тебя только FastTemplate. Гыыыыыыы :yees:

img элемент IE не закрывает. Тоже убрать? А как быть с font? И его убрать? Может сразу перейти на VbCode :cool: ...

Hubbitus
Да, еще отвечая на все твои вопросы об экстракоде Smarty и концепции разделения,
Да, это будет программированием вывода. Но зато мы разделяем программирование вывода от программирования сайта. Важно в данном случае не то что в коде (сайта) не будет задаваться переменная цвета (конечно значение можно прописать в шаблоне), важно то что переменных цвета вообще (!) не будет и т.п. Именно это дает полную независимость бизнес логики от оформления.
Нагляднее всего выгода от этого прослеживается когда меняется дизайн сайта и вместо меню скажем в одну колонку меню становится в две колонки (в первом четные, во второй нечетные), программер PHP отдыхает. Однако главное не то что он отдыхает, главное то что если на движке этого сайта работают еще два сайта (скажем клоны, расчитаны на другие ниши) то в их PHP коде ничего не поменяется, потому что так и должно быть -- офорление вторично. Следующая "версия" сайта подойдет под все эти сайты с минимумом правок PHP (или вовсе без них).

RaZEr
Зачем существует VbCode мне непонятно. Скорее кто-то (тоже очень мудрый) подумал что HTML разметка очень сложная -- давайте заменим ее на "попроще". На мой взгляд VbCode только усложняет жизнь, выучить пару тэгов HTML не составляет труда и полезней чем помнить VbCode.

Имиджи можно закрывать автоматом, можно не закрывать, еще еще еще еще еще раз плюну в тебя функцией htmlspecialchars() которая спасет тебя от любого невалидного HTML внутри XML.

Какая-то странная у тебя тактика меня достать... Оставляй <font> если нужно или вырезай <font> если не требуется :idontnow:

Мне VbCode нравиться тем, что теги пишутся без шифта :) А так конечно HTML был бы проще. Но разработчики рассудили верно - зачем зависеть от надежности striptags(), когда можно написать свой мини-парсер, который по крайней мере с родными багами :)

Десять раз я сказал что нужна разметка, а не текст и десять раз ты мне предложил превратить её в текст :)

Это лишь пример (я имел ввиду тот факт, что тег font устарел). Там много примеров ... те же кавычки которые то одинарные, то вообще отсутствуют. И & он на &amp; никогда не заменяет. И ещё там масса примеров.

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

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

Я вообще ничего не хочу решить :) Со своими подходами к этому вопросу я давно определился.

Я просто говорю тебе о том, что XML более зависим от своей "валидности" нежели какой-нибудь самопальный темплейтер "раз и готово". Вот есть например ламерский парсер заменяющий {имя_переменной} на значение. Он рулится обычными регами и в самом страшном случае просто заменит тег на пустую строку или же оставит нетронутым (если тот не попал под регу). XML же куда более капризен. Упаси меня не закрыть какой-нибудь тег или оставить невалидный символ, - сразу парсер эррор и всё сорвано.

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

RaZEr
В каком случае тебе не подойдет текст, о котором ты говоришь тут:
(исключая случай когда надо в клиентском (неизвестно валидном или нет) коде <p>...</p> заменять на <div class="roundcorner"><div class="top">...<div class="bottom"></div> и т.п. -- таким не занимается ни одна система темплейтов мне известная).

Помнишь с чего я начал?Именно это я и хотел донести.

RaZEr
Я уж кажись привел пример. Не шибко сложный был, да :)

Да. Только явно не в кассу. Практика показывает, что пока с внедрением XML немало проблем. Это не моё мнение, это - факт.

Нееееет, не стоит такого назначения выбрать оптимальную систему из существующих, видимо ты совсем так ничего и не понял, а споришь!!! Стоит вопрос сугубо теоретический, как делать лучше, как отделять, на каком принципе и т.д. Гдя я написал что мне нужно что-то готовое, или рассмотреть нужно из существующих, или я хочу выбрать какой-то готовый инструмент? И RaZEr крайне прав, приводя недостатки того или иного. Тебе я тоже очень благодарен за первый твой пост, где ты корректно и полно описал преимущества того что тебе нравится использовать... только не нужно зацикливаться, и критикуя этот подход мы (я покрайней мере), не тебя критикую, как его пользующего, а именно стараюсь выделить недостатки и изъяны...
Можно поподробнее в чем он состоит, этот подход? Я чего-то все меньше понимаю в этом вопросе, как мне кажется :beer: Это факт, который обсуждается где только не лень, почти на каждом форуме подобной тематики, и я уже приводил пару наиболее авторитетных линков...

RaZEr
Пока что ни одной неразрешимой проблемы я не услышал. Это тоже факт :cool:

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

RaZEr
Очень умно. Но я не вижу ни одной проблемы которая была бы столь сложной что заняла бы больше времени чем какая-нибудь рядовая задача ;)

В этом всё дело, что проще написать (ещё проще взять готовый) новый темплейтер, чем решать проблемы связанные с использованием XML-парсеров.

RaZEr
Это уже другой вопрос. Собственно это я и хотел услышать.

Ну слава богу. Не подрались - уже хорошо ;)

А по существу. Есть идеи как грамотно превратить невалидный XML в максимально валидный?

RaZEr
Чтоб ты не подумал ничего хорошего я имел ввиду что это соответсвует натуре человека -- чем разобраться в XML и XSL легче конечно взять готовое или написать заново то что уже давно написано ;)

Максимально валидного XML не бывает (бывает валидный или нет). XML по сути не предназначен для правки человеком (хотя и не исключает этого). XML должен создавать программист (через скрипт) а не пользователь. Если прораммист граммотный то XML будет валиден всегда, даже если содержит текст пользователя. Если текст пользователя содержит HTML то его можно автоматом приводить к XHTML либо пропускать через htmlspecialchars(). Я еще не видел написанной кем-то реализации HTML->XHTML, наверное от htmlspecialchars() никто пока не страдал.

А как же вы, любезный, поступаете, когда не повезло с хостингом? "Качество не моей мануфактуры"?...
maximum = as much as possible = как можно более.
Цитата с W3C будет?
Ты уже дал ответ на этот вопрос:

как это я не заметил такую интересную дискуссию?:)

про валидный xml:

есть xml-схема, есть DTD, есть прочее, т.е. проблем с проверкой нету, есть проблема с составлением правил(что обрезать, а что нет).

про xslt:

предлагается следующее упражнение(типичная задача для вывода каталога):

1. есть некоторый xml-файл с данными(там только данные, как и предложил denver). что-то типа:

<catalog>
<item>
<id>1</id>
<title>АААААААА</title>
</item>
<item>
<id>2</id>
<title>БББББББББ</title>
</item>
<item>
<id>3</id>
<title>ВВВВВВВВв</title>
</item>
<item>
<id>4</id>
<title>ГГГГГГГ</title>
</item>
</catalog>
....

2. есть некоторый шаблон(xslt).

3. есть код на php, который выдает html(ну то есть типа: $xsltInstObj->out("my.xml","my.xsl");)

внимание задача:):

вывести все данные в n-столбцов, отсортированные свверху вниз, т.е. типа:

а г ж й
б д з
в е и

за n возьмем - 4(столбца)

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

если еще усложнить задачку, то вывод должен быть таким:

<table>
<tr>
<td>
1 элемент 1 столбца
</td>
<td>
1 элемент 2 столбца
</td>
<td>
1 элемент 3 столбца
</td>
<td>
1 элемент 4 столбца
</td>
</tr>
</table>

по идее в подходе Денвера, это логика вывода, которая ложится на верстальщика. Завтра все приходим на работу и даем задание верстальщикам, о результатах пишем здесь:)

Sheryld
Ну формулой будет ceil(count($items)/$n)) тут долго думать не надо. Особенность реализации зависит от конкретного языка будь то Smarty или XSLT, скорость реализации зависит от знаний/опыта верстальщика в этом языке.

Да, XSLT это в язык прораммирования (только вывода). Однако смешно смотреть на сборище снобов пэхапэшников которые так наивно уверены что верстальщик не может (не в состянии, не хватит мозгов, куда там) выучить язык программирования, что это только пэхапэшнику дано, но пэхапэшнику скучно его учить. Почему бы не рассматривать это и так: "нам нужен программер PHP(соотв. +MySQL,+Unix, etc) и программер XSLT(соотв. +HTML, +CSS etc)"? "Программер" XSLT будет ненамного дороже верстальщика HTML, однако в результате это будет настоящее отделение контента от оформления.

RaZEr
В спецификации PHP тоже не написано что код не предназначен для правки пользователем, тем не менее, ты обычно не советуешь заказчику менять даже константы в коде.
Аналогично хочется спросить -- "максимально валидный XML" -- цитата с W3C будет?

From RaZEr: Денвер! Личку - в ПС. Демогогию эту устраивай в другом месте!

дьявол кроется в деталях.

покажи реализацию на xslt.

Sheryld
Ну скажем вот решение для n=4:
Может шокировать конечно количество XSL кода (можно было бы обойтись без переменных, но так нагляднее и удобнее), на практике HTML намного больше конечно. В любом случае не вижу особенных слжностей, на Smarty решение было бы похожим.

не знаю как вам, мне определенно понравилось.

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

Интересно, а разбираться в уже написанном (тотже Смарти) или темболее написать что-то свое это лень разбираться с XML и XSL??? Странная логика однако, вот ведь лентяи блин, эти создатели Smarty!...

Причем же здесь W3C. Это не утверждение, а формулировка. Вполне понятная. Необходимо (было) добиться максимально возможного приближения HTML к XHTML. Но да ладно, - вопрос снят. От греха подальше, как говориться :beer:

Если у нас есть: А - набор информации выданной скриптом, Б - шаблон определяющий порядок и количество информации, В - стиль оформления задающий внешний вид. То мы можем создать XHTML при помощи PHP, а затем его оформить XSLT стилем. Тогда все останутся довольны :beer:

Hubbitus
PHP в качестве языка логики оформления :rolleyes: Ну это ты вернешься к тому с чего начал: <?=$color?> и т.п., тоже неплохо собственно ;)
А если серьезно, то просто возникнет вопрос безопасности, PHP в этом плане шибко мощный.

RaZEr
Эээ.. тоже конечно можно. Однако это получится что из одного шаблона мы делаем другой шаблон, а потом уже HTML.

ЗЫ. :beer:

тут есть одно фундаментальное преймущество.

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

я вобщем об этом писал, немного выше:

пока так и делаю. есть конечно соблазн попробовать сделать вывод xml+xslt, но пока не решаюсь, слишком много подстав(тут уже о них писали, я добавлю одну: огромное кол-во верстки и кода, который нужно перелопатить — времени на это нет).

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

я не о php в целом, а о smarty в частности.

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

пример: переезд сайта с php на asp.net.

Пример плохой (не часто такие переезды происходят), но я с тобой согласен - из связки FastTemplate, Smatry, XSLT последний будет предпочтительнее.