Разное

Какой выбрать движок шаблонов для большой системы?

- важно время обработки
- функциональность

В Smarty шаблоны компилируются 1 раз в PHP код. Т.е. шаблоны в принципе во время работы не используются вообще, а время обработки полученных скриптов зависит только от обработчика PHP-кода. По функциональности меня вполне устраивает. Если будет не хватать стандартного набора, можно добавить свои функции.

> время обработки полученных скриптов зависит только от обработчика PHP-кода

Smarty и написан на PHP, поэтому как-то странно звучит. В любом случае, стандартное демо Smarty у меня выполнилось за 0.603826999664 секунды. Очень долго. После кеширования - 0.316951036453. Немногим лучше.

Так что лучше написать под себя какой-то шаблонизатор.

И я о том, возможно есть уже написанные которые работают быстрей, знаете такие?

FastTemplate, например... обратитесь в гугл:) не знаю, возможно, есть интерфейс к Template Toolkit...

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

Шаблону то откомпилироваться дали? Или это приведено время первой компиляции?

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

> Шаблону то откомпилироваться дали?

Естественно.

> Ну а есть вообще другие шаблонизаторы кроме смарти?

Конечно. Например, xTemplate

Ну а есть вообще другие шаблонизаторы кроме смарти?

Вообще-то Smarty - это велосипед, как всегда выдуманный PHP-разработчиками, и который никогда не будет стандартизирован. Если и ориентироваться на стандартизированные технологии, то лучше использовать HTML, XML, XSLT и CSS - эти технологии не только стандартизированы, но и обрабатываются на стороне клиента, снимая нагрузку с перегруженного сервера.

cheops, как Вы можете сравнивать шаблонизатор и языки разметки / стили? Удел шаблонизаторов - отделять разметку от программного кода, это естественно никто не будет стандартизировать - это уже личные предпочтения разработчика, они никак не касаются пользователей.
И это никакие не взаимозаменяемые вещи, чтобы говорить что лучше использовать - Smarty или HTML...Шутите что ли...

Нет не шучу. XML и XSLT на роль шаблона чем не подходит? Причем заметте, что язык шаблона (XML-файл) вы можете создать сами - под свои задачи (как в ООП), а не использовать навязанные самопальным шаблоном, про который через 5 лет никто вспоминать не будет.

PS Если за шаблонами следите, то заметите, что стандартизацией и не пахнет - надобности нет, все давным-давно уже выдумано и даже поддержка реализована. Не доверяете браузерам? Можете компилировать XML+XSLT на стороне сервера - в PHP имеется стандартное расширение. И это стандарт, то что будет работать и через 10 и через 20 лет.

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

>Вообще-то Smarty - это велосипед, как всегда выдуманный PHP-разработчиками

Очень хороший велосипед выдумали )) Во-первых синтаксис велосипеда был разработан, чтобы не распугать html-верстальщиков, которые знают HTML, CSS и ,максимум, ещё JS.
Во-вторых обрабатывать шаблон на стороне клиента не всегда возможно в принципе (клиенты мобильников). Так что велосипед вполне оправдывает себя.

На стороне сервера XML & XSLT так же должны каждый раз заново обрабатываться из текста?

Сервер генерит данные в формате xml, а клиент (браузер) представляет эти данные в любом виде посредством XSLT трансформации xml документа.

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

Так что XSLT + XML в идеале лучший шаблонизатор. Другое дело, что вроде бы не все браузеры имеют XSLT процессоры. И приходится делать эти преобразования на сервере (Sablotron, etc). Поправьте меня, если не так.

Трехколесный велосипед на определенном этапе штука вероятно тоже не плохая, другое дело, что он детский, и 40-летний пузатый дядя на нем выглядит комично.
Верстальщику, который знает HTML и CSS, Smarty все-равно изучать приходится, так не проще ли сразу XML и XLST, которые к HTML стоят гораздо ближе, чем тот же Smarty?

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

Пожалуй единственный разумный довод, другое дело, что от Smarty рано или поздно придётся отказываться в пользу XML+XSLT, которые рано или поздно придётся изучать.

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

> если удобный инструмент нестандартен - нафиг такие стандарты:)

Разрешите подписаться.

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

Да и нынешняя схема трёхступенчатового утверждения RFC просто тормозит прогресс. Стандарты устаревают не успев стать таковыми.

Стандартизировать Web-приложение на PHP ориентированное на PHP же? Проще IE объявить стандартным браузером.

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

>Короче, если удобный инструмент нестандартен - нафиг такие стандарты:)
Тут, согласен. Особенно если инструмент доминирует в своей нише, вроде PDF, Flash, JavaScript, Perl-регулярных выражений. Однако, не сказал бы чтобы какой-то шаблон или браузер доминировали - тут и нужны стандарты, если вас много - придерживайтесь правил. Иначе заказчикам и разработчикам придётся тратить слишком много денег и времени на разработку (а их и без того есть куда применить).

>Стандартизировать Web-приложение на PHP ориентированное на PHP же? Проще IE объявить стандартным браузером.
Не совсем так. Опущен тот момент, что разработкой смарти занимается та же команда что и разработкой php. Как я понимаю, они в любой момент могут сделать из смарти модуль для php и включить его в стандартную поставку php. И будет смарти стандартнее всех стандартных:)

>придётся тратить слишком много денег и времени на разработку
Тут вы сами себе противоречите: если инструмент удобный, то в нем без проблем разберется разработчик даже не знакомый с ним, а если инструмент попросту стандартный но неудобный, то его код придется долго и муторно разбирать программисту любой квалификации. Это - так... личные впечатления:)

>>придётся тратить слишком много денег и времени на разработку
>Тут вы сами себе противоречите: если инструмент удобный, то в нем без проблем разберется
>разработчик даже не знакомый с ним, а если инструмент попросту стандартный но
>неудобный, то его код придется долго и муторно разбирать программисту любой
>квалификации. Это - так... личные впечатления:)
Не хочется вдаваться в длительную дискуссию, можно подобрать множество ситуаций когда я полностью соглашусь с вами, а вы со мной, а уж когда дело дойдет до реальных условий - наши действия и выбор инструментов скорее всего будут идентичными. В большинстве случаев следует подходить прогматически, рассматривая сколько в запасе людей, денег, времени, сколько будет жить проект и сколько платформ обслуживать. Полностью согласен, что охотиться на танке за белками не удобно, однако, при рытье трашеи я предпочел бы иметь экскаватор и опытного тракториста, чем взвод солдат, которые смогут быстро разобраться с устройством лопаты :)

>чем взвод солдат, которые смогут быстро разобраться с устройством лопаты :)
Солдаты обойдутся дешевле:)

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

Можно мне чуточку кулаками помахать?) Хорош Smarty, плох Smarty - это тема для долгой дискуссии, но вот когда все делаешь один, то Smarty - это просто неоценимая вещь. Да и расходов никаких - "лопата" легко понятна в изучении, и солдат всего один. Главное, это то, что хорошо видно где траншея окопа, а где бруствер для орудий, и легко можно подчищать сам окоп, и с земелькой возиться отдельно.)

Не приходилось мне иметь дела со Smarty, да и как-то ни на одном собеседовании о нем речь и не шла.. Хотят Symfony, CodeIgniter, ну и Zend..

Так это, извиняюсь, фреймворки...

Значит лучше смарти нечего нет, если не брать во внимание XML и т.д. хоть он и тормозит немного процесс...

> Значит лучше смарти нечего нет

А Вы пробовали что-то другое?