Разные шаблонизаторы. Плюсы и минусы.

[Angerslave]

Разные шаблонизаторы. Плюсы и минусы.

Вот недавно встал вопрос о выборе шаблонизатора. Пока добрался только до Smarty и XTemplate. Первый честно говоря немного оттолкнул своим размером и навороченостью, поэтому начал юзать второй. Только вот беда - особо не развернёшься(то есть, например, новости можно только в ряд, в строчку, таблицей... но по 3 уже не получится(придётся лезть в код скрипта)). Поэтому вопрос - кто что выбирает? Даёт абсолютный простор фантазии дизайнеру и верстальщику или выбирают скорость? Если XTemplate всё же медленнее(хотя верится в это с трудом) - прошу обосновать Желательно примерами

 

[AmdY]

если только недавно добрался, юзай смарти.

 

[Angerslave]

AmdY, почему его? Вроде синтаксис его немного сложнее синтаксиса xtpl...

 

[Фанат]

но по 3 уже не получится

да ладно.
все там получится.
вкладываешь один блок в другой - и вперёд.
другое дело, что при использовании XTemplate "придётся лезть в код скрипта" в любом случае. Это пример шаблона, который состоит из двух файлов - шаблона и логики. А в Смарти все объединено в одном, что удобнее.

вопрос - кто что выбирает? Даёт абсолютный простор фантазии дизайнеру и верстальщику или выбирают скорость?

лично я выбираю то, что даёт и то и другое - PHP! ;-)

Если XTemplate всё же медленнее(хотя верится в это с трудом) - прошу обосновать

забудь про скорость. Это не тот вопрос, который должен тебя волновать

 

[AmdY]

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

 

[Sender]

Angerslave
xml/xslt связку еще посмотри

 

[Angerslave]

Sender, в инете что-то почитал, сказали что многие не справляются. Типа слишком сложно даже для середняка(хотя я себя и таким не считаю).

 

[Фанат]

кто что выбирает? Даёт абсолютный простор фантазии дизайнеру и верстальщику или выбирают скорость?

вообще-то, в этой фразе заключено целых два заблуждения. в смысле - три, если считать скорость, но про неё я уже писал.
1. Шаблонных движков, которые "ограничивают фантазию" в природе не бывает. Вообще. Как двухколесных автомобилей. Если какой и ограничивает, то он просто нигде не используется.
2. XTemplate ограничивает свободу "верстальщику" не тем, что тот не может что-то реализовать, а тем, что ему приходится учитывать код, содержащийся в скрипте. про это, впрочем, я уже тоже написал.

 

[AmdY]

Sender
xml+xslt -
человек начинает въезжать в шаблонизацию, а тут его с тяжёлой артилерии.
а самое плохое, что очень трудно найти дизайнера, придётся шаблоны натягивать самому.

 

[Фанат]

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

 

[Angerslave]

вообще-то, в этой фразе заключено целых два заблуждения. в смысле - три, если считать скорость, но про неё я уже писал.
1. Шаблонных движков, которые "ограничивают фантазию" в природе не бывает. Вообще. Как двухколесных автомобилей. Если какой и ограничивает, то он просто нигде не используется.
2. XTemplate ограничивает свободу "верстальщику" не тем, что тот не может что-то реализовать, а тем, что ему приходится учитывать код, содержащийся в скрипте. про это, впрочем, я уже тоже написал.

Хм, с первым наверное согласен, со вторым нет. По-любому приходится учитывать код скрипта. Хотя бы при выводе переменных. Другое дело, что в смарти вроде как можно PHP-код писать, а в XTemplate нельзя(если неправ - прошу не кидаться камнями - времени на изучение доков было мало).

ПС. А третье заблуждение какое?

 

[AmdY]

кстати. можно поступить проще.
спроси "Что даёт абсолютный простор фантазии дизайнеру и верстальщику", у них самих.

если выберут xslt, пиши куда слать пиво.

 

[Фанат]

ну, код скрипта приходится учитывать на уровне обмена данными. Это само собой разумеется.
в смарти нельзя PHP-код писать. и не нужно. код смарти - это сам по себе язык - не хуже пхп.
я о другом.
шаблон на смарти, или шаблон на пхп, или на XSLT, или на любом другом языке, который полноценно поддерживает логику, общается со скриптом только на уровне передаваемых в него данных.
Шаблону же без встроенной логики - такому, как XTemplate - требуется прокладка между скриптом и шаблоном, которая интерпретирует управляющие конструкции шаблона. и в неё лезть придётся обязательно

-~{}~ 30.01.07 17:27:

а третье заблуждение - это про скорость. Будто она на что-то влияет.

 

[Sender]

AmdY
Angerslave
не знаю насчет сложности... ничего сложного там нету, я бы сказал это вопрос привычки и приемлемости...

для меня смарти сложен, но не потому что он сложный, а потому что я к xslt привык... и со смарти имел дело мало.

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

 

[Syava]

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


Sender : я за 5 лет программирования перепробовал много вариантов шаблонных процессоров. И похожие на шаблонные процессоры с подстановкой (str_replace), и что-то похожее на смарти. Но они все требуют инициализации данных до работы процессора, что не хотелось бы, т.к. шаблонный процессор это должен выполнять как отдельно стоящий модуль. Так вот в последнее время я склоняюсь к XML, но здесь опять свои недостатки:
- при больших шаблонах (чего не избежать для порталов) повышенная нагрузка, т.к. при разборе появляются копии ветвей
- строгие критерии валидности XML шаблонов, что приводит к завершению выполнения сценария в случае неудачи.

Вот такие мысли, если не прав критикуйте.

 

[Фанат]

Syava

логикой должен заниматься логический уровень сценария.

а кто спорит-то?
ты не найдёшь здесь ни одного человека, который скажет против.

Но они все требуют инициализации данных до работы процессора

Это ты к чему? К тому, что последнее время я склоняешься к XML?

 

[Sender]

Syava
требования валидности еще никогда не были недостатками, это скорее достоинства

насколько я знаю основное время при xslt преобразовании занимают XPath запросы.
есть мысль кешировать результат xslt преобразования, а в xsl писать:
<xsl:if test="count(BLOCK_CACHED)">
выводим кеш (по сути html готовый )
</xsl:if>
... иначе выполняем преобразование

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

например обозначать в конечном html эти блоки и потом их распарсивать регулярками и кешировать соответственно

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

 

[AP]

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

 

[Фанат]

больше возможностей

пример

код валидатный получается...

это шутка?

 

[AP]

xslt - стандарт w3c!
Что касается больше возможностей, то вставка в php-кода, написание собственных функций, не бажный...