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

[y13]

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

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

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

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

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

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

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

[RaZEr]

Так что ты хочешь сказать, что скажем Smarty наплевать на валидность/инвалидность значит он может заменить

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

то этот текст по определению является контентом и значит по определению не должен включать элементы оформления

Почему же. В содержимом мы задаём логику документа => если тот же клиент имеет возможность вводить содержимое, то он и логику может задавать.

все тэги оформления и другие от которых может "поехать" дизайн всего сайта вырезаются

Т.е. если клиент написал в коде <img ...> то я должен его вырезать? А кому такой CSM нужен будет тогда...

[denver]

RaZEr

Я хочу сказать, что если ты используешь XML/XSLT ты должен обеспечить валидный XML источник, а в случае с шаблонизаторами вроде <?=$some?> я могу позволить себе писать такой HTML какой хочу.

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

Т.е. если клиент написал в коде <img ...> то я должен его вырезать?

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

y13

Маше, Васе и потребителю до лампочки, что там использовал Петя

Это глупый менеджер так поначалу всегда думает, ага... И точно точно, гляди, вот так же подчеркивает эти слова!
А потом:

Никакой шаблон недолжен нести код. Мы помним, что этот самый шаблон рисовала Маша, а она ни php, ни perl даже в глаза не видела

Это он потом уже типа думает, ага... А может вообще не подумать, а Маша и Петя будут его вспоминать нехорошими словами, пока не сдадут проект.

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

[RaZEr]

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

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

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

[denver]

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

[RaZEr]

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

[y13]

Сообщение от denver

RaZEr

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

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

y13

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

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

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

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

[denver]

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

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

простой тег <p> может быть в дизайне представлен красивым блоком с округлыми краями

Я не видел ни одного сайта где такое реализовано, и вряд ли будет до выхода CSS3 (а в мозилле уже есть вон -moz-border-radius межпрочим, говно, а и то хорошо)

y13

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

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

[Hubbitus]

denver:
Так ты все же сначала разберись что ты хочешь-то дайте мне идеальную систему темплейтов и конечно быструю, и простенькую чтобы... FastTemplate!

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

denver:
XSLT всем хорош. Но зачем упоминать все его достоинства если в рамках данного топика это оффтопик. Я думаю что и Smarty при желании можно делать то-же самое, только это никому особо не нужная функциональность.

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

RaZEr:
основной предмет разговора - полное и грамотное разделение оформления и содержания.

не больше не меньше, пока мы даже не пришли ни к какой конкретной ("грамотной" или идеальной, если хотите) концепции разделения!!

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

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

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

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

denver:
На твоем бы месте, весь код от этой HTMLArea на выходе обрабатывал бы автовалидатором (автоматом закрываем все тэги). Если ты считаешь что это тупо то что поделать -- ты хочешь и на... сесть и рыбку съесть

Кстати незнаю как для тебя denver, но это крайне актуально на самом деле, ты видел какой код формируется в таком WYSIWYG редакторе? Там помоему сам Гейтс не сможет часто объяснить как это так вдруг так получается! А еще нужно учесть подобные прибпмбпсы для разных браузеров...

[denver]

Hubbitus
Да, я видел что получается из HTMLArea особенно если в нее копипэйстить мсворд. Однако все проблемы не так актуальны если юзать:

PHP код:

$allowed_tags='<a><br><b><h1><h2><h3><h4><i>' .
             '<img><li><ol><p><strong><table>' .
             '<tr><td><th><u><ul>';
$userhtml = strip_tags($_POST['userhtml'], $allowed_tags); 


Именно этим я и занимаюсь - разбираюсь что же собственно требуется от шаблонов в общем случае

В общем случае требуется:

denver:
1. Отделение PHP кода от HTML кода.
либо
2. Отделение бизнес логики от логики отображения.

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

[RaZEr]

Однако все проблемы не так актуальны если юзать

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

[denver]

Hubbitus
Да, еще отвечая на все твои вопросы об экстракоде Smarty и концепции разделения,

это ли уже будет в итоге не программированеи вывода, только верстальщиком????

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

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

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

А как быть с font? И его убрать?

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

[RaZEr]

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

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

плюну в тебя функцией htmlspecialchars() которая спасет тебя от любого невалидного HTML внутри XML

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

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

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

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

[denver]

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

[RaZEr]

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

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

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

[denver]

RaZEr
В каком случае тебе не подойдет текст, о котором ты говоришь тут:

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

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

[RaZEr]

Помнишь с чего я начал?

Вы не забывайте, что XML будет посложнее в реализации

Именно это я и хотел донести.

[denver]

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

[RaZEr]

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

[Hubbitus]

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

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

RaZEr:
Со своими подходами к этому вопросу я давно определился.

Можно поподробнее в чем он состоит, этот подход? Я чего-то все меньше понимаю в этом вопросе, как мне кажется

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

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