Xpoint
   [напомнить пароль]

Smarty или XSL/XSLT - вопрос выбора

Метки: [без меток]
2007-12-20 15:43:05 [обр] wiktar(0/20)[досье]

Интересно,

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

Под Smarty здесь я принимаю все подобные шаблонизаторы: сам Smarty, Template-Toolkit, да и PHP.

И второй вариант: XSL/XSLT-преобразования. Тоже позволяют объединить содержание и представление, но уже не императивным, а декларативным способом.

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

спустя 1 час 2 минуты [обр] Pil(0/22)[досье]
wiktar[досье] ИМХО лучше использовать общепринятые, универсальные средства — XSL/XSLT.
спустя 1 минуту [обр] Pil(0/22)[досье]
В догонку: Вы подсознательно сами ответили на этот вопрос, разместив тему не в форуме по PHP, а в более концептуальном.
спустя 5 часов [обр] wiktar(0/20)[досье]

Pil[досье] прямо таки, общепринятые.

Например, часто врубать мощь XSL/XSLT бессмысленно.
Вначале в движке нужно сгенерировать XML, а потом на него натянуть XSL.

Зачем?

И в то же время, когда-то оно нужно.

Вот и интересно, в каких случаях что.

спустя 4 дня [обр] Андрей Пахомов(0/310)[досье]
А какая там мощь то в XML/XSLT ? Только стандартизованность и возможность использовать практически в любом языке. Но если надо какие то вещи - тот же самый ведомый контроллер - то в случае XML надо уже пользоваться расширениями, которые уже специфичны и опять таки привязывают к конкретной платформе. Другое дело что XSLT трансформер, как правило, написан на Cи и работает реально быстрее чем тот же Smarty. Поэтому смысл использовать XML/XSLT - в тяжелых проектах, чтобы с проблемой обучения разработчиков не сталкиваться и в случае необходимости иметь возможность перейти на другую платформу (ту же Java или .NET) не изобретая велосипеды и не перелопачивая сотни шаблонов. Тот плюс, который еще вписывают XML-ю - отделение дизайна от данных. Но реально, смена дизайна, вшитого в XSLT - ничуть не проще переписывания шаблонов, те же самые конструкции циклов и условные операторы. Поэтому дается легко только при наличии нормального документирования, что свойственно опять таки достаточно крупным проектам. Также стоит учитывать, что мелкие сайты обычно народ хостит явно не на VPS и не на колокейшн серверах, поэтому требовать от хостера чтобы он для сайта-визитки поддерживал XSLT - явно излишне. А вообще к этим технологиям надо относиться без фанатизма - всему своя ниша и XML/XSLT - это явно не для SOHO, поэтому внедрять это в мелкие проекты можно только для приобретения опыта.
спустя 32 минуты [обр] Kirill(0/3)[досье]

Андрей Пахомов[досье]
"отделение дизайна от данных". Именно. Вы же сами пишете - "смена дизайна". Очевидно, что при смене дизайна надо менять шаблон, который дизайном и занят. Но код, генерирующий xml, трогать не надо вообще (программист не нужен). В этом и смысл.
"работает реально быстрее чем тот же Smarty". Верно. Ну и при чем тут VDS для применения XSLT ? Вы сами себе противоречите. И от хостера ничего не надо требовать, покажите мне хостера, который стандартные расширения PHP (dom, xslt) не поддерживает :)

wiktar[досье]
Дополнительный плюс в XSLT шаблонизаторе - возможность полностью распараллелить работу программера и верстальщика. тесткейсовый xml пришется руками, далее программер пишет код, генерирующий этот xml, верстальщик пишет шаблоны xslt, его использующие. ИМХО - я использую связку xml/xslt на всех проектах без исключения от визиток до сложных, ни разу не замечал ни тормозов, ни иных проблем. Даже если не кешировать трансформ. Минус - после использования xslt использовать Смарти просто невозможно :)

спустя 1 час 1 минуту [обр] Андрей Пахомов(0/310)[досье]

Kirill[досье]
Ы ?

Очевидно, что при смене дизайна надо менять шаблон, который дизайном и занят. Но код, генерирующий xml, трогать не надо вообще (программист не нужен)

а типа в смарти нужен ? По моему эта фраза вообще относиться к любым шаблонизаторам с нормальным функционалом. И еще: поясните мне разницу в опыте, который требуется верстальщику чтобы поменять вот такой кусок:

<ul>
{{section name="i" loop=$list}}
<li {{cycle values=',class="int"'}}>{{$list[i].cdate|date_format:"%d.%m.%Y"}} <a href="/info/news/{{$list[i].cdate}}/{{$list[i].id}}">{{$list[i].name}}</a></li>
{{if $list[i].cdate>$max_date}}
    {{assign var="max_date" value=$list[i].cdate}}
{{/if}}
{{/ul}}

на что то другое и вот такой:

<div id="navigate_line">
    <xsl:for-each select="a">
    <a id="{@id}" href="{@href}"><xsl:if test="../@current = @id">
        <xsl:attribute name="class">bt_current</xsl:attribute>
    </xsl:if><xsl:value-of select="."/></a>
    </xsl:for-each>
</div>

При этом человек если не знал, ни того, ни другого, в чем он быстрее разберется ? в доке по смарти или в RFC по XSLT ?

Параллелить работу можно при использовании ЛЮБОГО шаблонизатора. А еще покажите мне пример использования ведомого контроллера в случае XSLT, который бы работал и на PHP, и на Perl-е, и на Java.

По поводу хостеров - сейчас не скажу, уже давно не пользуюсь их услугами, но отвечать за всех хостеров я бы не стал. Бывали случаи, когда меня за поддержкой Postgres в VDS отправляли, тот же majordomo.ru где то год назад, а некоторые говорили - надо ? пишите, мы пересоберем. Или вообще не реагировали на письма и просьбы. И когда клиент в погоне за экономией 10 ти долларов не может понять на кой ляд мне нужна от хостера поддержка XSLT, WDDX и MySQL 5.1 или Postgres 8.1 и ему кроме как сказать, сайт, понимаешь, пользует enterprise futures - нечего, при этом у него сайт в 10 страниц и посещаемость в 20 человек в день. Специально поинтересовался сейчас - тот же majorodmo.ru до сих пор не поддерживает WDDX из коробки. А может я хочу XSLT прямиком на сериализованные в WDDX объекты намазывать ? Может другие хостеры и поддерживают все нормально. Но клиенты не всегда слушают что им говорят, и порой находят хостинг сами или через знакомых. И с этими наворотами порой такие интересные баги находишь в поддержке этих средств. Поэтому для мелких проектов у меня действует правило: чем проще и непритязательней - тем лучше. Во всем, конечно, надо знать меру и в plain db вместо mysql-я уходить - это уже излишний аскетизм, но и на хомяк XSLT натягивать - это уже пустая трата сил и средств.

спустя 4 месяца 3 дня [обр] Степаныч(0/50)[досье]
ИМХО XSLT не для людей, или не для нормальных людей. (Столкнулся с хосткмс и понял, что даже Smarty всё решилось бы быстрее.)
И ещё. Нужен ли шаблонизатор или достаточно нетив php или что там у вас? Что за задача? Вообще, любой теоретический подход - блаж и преждевременная оптимизация. Например, если в системе уже XML\XSLT, то куда деваться? Если у бабушки... :)
Powered by POEM™ Engine Copyright © 2002-2005