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

[dacuan]

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

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

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

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

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

Это верно, но во-первых можно поизвращаться, поудалять лишние пробелы и т.п. Для примера можно посмотреть формат файлов OpenOffice.
Во-вторых, XML можно рассматривать как участок PHP-кода, в котором происходит занесение переменных в шаблон (те самые assign()) и я не думаю, что такие два подхода будут сильно разнится в размерах, но остается открытым вопрос скорости, нужны бенчмарки.
В-третьих, собранный XML пожно использовать как один из уровней кеша. Это может быть удобно при реализации двух версий сайта HTTP и WML, когда наполнение одно и то же, но разнятся форматы отображения.

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

Во-вторых - поддержка XML/XSLT в разных языках может все-таки различаться.

XML/XSLT это уже признанный стандарт с четкими RFC и я не думаю, что различные реализации не поддерживают RFC. В ПХП есть возможность использовать libxml, libxslt, эти же библиотеки можно использовать и на перле и на си, думаю, есть и возможность прикрутить ее к asp и иже с ними, хотя в нем есть своя реализация xml.

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

И в третьих - я понимаю конечно, что можно написать все, в т.ч. хранить данные в БД, а потом их конвертировать в промежуточную форму (XML например) но ведь это изврат помоему, да и долго.

Генерация XML не займет времени дольше, чем генерация HTML со вставками вида <?=title?>. Возможно, получится генерацию ускорить за функций для работы с DOM XML, но опять же нужны тесты. Так что, с определенной точки зрания, генерация HTML и генерация XML одно и то же, разве что структура XML будет проще, так как нет необходимости вставлять теги форматирования, следить за структурой таблиц и проч.
Но добавляется еще один этап при генерации шаблона - преобразование XML->HTML с помощью XSLT, так что использование XML для реализации шаблонов будет чуть медленнее, чем прямая генерация HTML. С другой стороны имеем ускорение разработки, за счет упрощения взаимной работы верстальщика и программиста и упрощается поддержка проекта, так как шаблонизатор стандартный (гораздо распространеннее FastTemplate, Smarty и проч.)

[Hubbitus]

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

dacuan:
Это верно, но во-первых можно поизвращаться, поудалять лишние пробелы и т.п. Для примера можно посмотреть формат файлов OpenOffice.

Насколько Вам известно, OpenOffice хранит свои файлы в XML, сжимая их архиватором, конкретно GunZip'ом. Это же неприемлемо для Веб-сайта с нормальной посещаемостью (даже если выделенный сервер не вижу причин так понапрасну расходовать процессорное время).

dacuan:
В-третьих, собранный XML пожно использовать как один из уровней кеша. Это может быть удобно при реализации двух версий сайта HTTP и WML, когда наполнение одно и то же, но разнятся форматы отображения.

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

dacuan:
XML/XSLT это уже признанный стандарт с четкими RFC и я не думаю, что различные реализации не поддерживают RFC.

HTML, DOM и CSS уже сколько лет стандарты, а поддержку одинаковую у разных браузеров все также ждут миллионы программистов/верстальщиков по всему миру Что касается XML - я НЕ сравнивал, и НЕ знаю о различиях реализации, но подозреваю что и тут камней будет море.
Может кто-то поделиться своим опытом в данном вопросе?

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

[dacuan]

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

Насколько Вам известно, OpenOffice хранит свои файлы в XML, сжимая их архиватором, конкретно GunZip'ом. Это же неприемлемо для Веб-сайта с нормальной посещаемостью (даже если выделенный сервер не вижу причин так понапрасну расходовать процессорное время).

Если быть точным, то в архиве несколько файлов XML, и не только они. Я имел в виду организуцию XML-фалов (в них все лишние пробельные символы удалены) но не достижение сверхмалого размера за счет архивирования.

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

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

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

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

HTML, DOM и CSS уже сколько лет стандарты, а поддержку одинаковую у разных браузеров все также ждут миллионы программистов/верстальщиков по всему миру.

Основная проблема несовместимости браузеров не в том, что они не поддерживают стандарты (стандарты в каждом браузере реализованы полностью), а в том, что каждый браузер по своему воспринимает отхождения от стандартов, хотя это мое ИМХО.

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

Что касается XML - я НЕ сравнивал, и НЕ знаю о различиях реализации, но подозреваю что и тут камней будет море.

Именно поэтому я и упомянул о библиотеках libxml и libxslt.

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

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

Именно так, при условии, что потери производительности не будут колоссальными . Ведь все с удовольствием пользуются фабриками классов, не смотря на то, что они отрабатывают в разы медленнее, чем прямое создание объектов. Да и, как видно из ветки, люди согласны жертвовать производительностью при выборе механизма шаблонизации, разница лишь в том, что шаблонизация с использованием XML, более общее решение, чем большинство шаблонных движков.

[Hubbitus]

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

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

Про функциональность в целом и совместимость такого подхода с использованием XML, я и не спорю. Меня инетерсуют также и другие факторы, и насколько "плюсы" перекрывают "минусы"!

dacuan:
Основная проблема несовместимости браузеров не в том, что они не поддерживают стандарты (стандарты в каждом браузере реализованы полностью)

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

dacuan:
Да и, как видно из ветки, люди согласны жертвовать производительностью при выборе механизма шаблонизации, разница лишь в том, что шаблонизация с использованием XML, более общее решение, чем большинство шаблонных движков.

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

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

[ctapuk]

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

[Hubbitus]

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

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

[dacuan]

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

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

Проблема становится насущной только при наличии фактов, подтверждающих, что увеличение лишнего объема существенно повлияет на производительность. Да и отношение объема тегов к объему полезного контента, в общем случае, будет невелико.

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

Меня инетерсуют также и другие факторы, и насколько "плюсы" перекрывают "минусы"!

Как я и писал в своем первом посте:

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

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

Ой, вот тут Вы не правы!!! Лучше всех стандарты поддерживает Мозилла (моя личная оценка процентов на 90-95)

Я же предупреждал, что это - мое ИМХО

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

Я не заметил в данной ветке всеобщего одобрения такой "жертвы".

Разве факт того, что человек использует шаблонный движок, не есть его согласие на "жертву"?

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

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

Подведем итог.
Предложенные технологии:
1) Синтаксис ПХП.
- плюсы - быстрый не требуется переучиваться, большая функциональность и поддержка всех возможностей ПХП;
- минусы - нечеткое разделение кода и дизайна, слабая переносимость шаблонов (при реализации проекта на другом языке, шаблоны придется переделать).
2) Стандартные шаблонизаторы (Smarty, FastTemplate)
- плюсы - более сильное разделение дизайна и кода;
- минусы - не так быстры, как синтаксис ПХП, при переносе проекта необходимо будет кроме основного кода переносить и шаблонный движок.
3) XML/XSLT
- плюсы - полное разделение дизайна и кода, хорошая переносимость (работа с XML/XSLT реализована в большинстве современных языков);
- минусы - неясен вопрос производительности (по крайней мере для меня), вводится промежуточный способ хранения данных (XML).

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

[Hubbitus]

dacuan:
Разве факт того, что человек использует шаблонный движок, не есть его согласие на "жертву"?

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

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

[dacuan]

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

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

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

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

[Hubbitus]

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

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

[dacuan]

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

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

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

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

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

[Hubbitus]

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

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

[dacuan]

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

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

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

[RaZEr]

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

[Sheryld]

имхо, для 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.

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

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

[Hubbitus]

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

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

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

[ReapeR]

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

[dacuan]

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

[Sheryld]

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

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

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

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

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

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

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