Реабилитация XML/XSLT технологий

    Здравствуй, Хабр. Некоторое время назад мы внедрили у себя в CMS наряду с уже имевшимся к тому моменту собственным шаблонизатором, еще и XSLT. Поскольку есть в XSLT большие и реальные преимущества и для разработчиков, и для хозяев студий, и даже для владельцев сайтов. Но реакция наших партнеров разделилась на противоположные мнения: одни давно ожидали этого и были рады появлению такой возможности, другие поставили под сомнение востребованность XSLT, приводя в качестве аргумента низкую производительность, которую якобы влечет за собой использование XSLT.
    Понятно, что у всего нового всегда есть сторонники и противники, и рассудит их время. Поэтому не было особого смысла развязывать религиозную войну XSLT vs tpl или Smarty на тот момент. Но мы обнаружили, что оказывается, один из лидеров российского рынка CMS с завидным упорством все пишет и пишет о якобы несостоятельности XSLT как массовой технологии и готов рассматривать ее только в контексте специфичных задач. А это негативно влияет на умы некоторых непосвященных разработчиков об XSLT.



    С другой стороны, прошедшая недавно крупнейшая европейская IT-выставка CeBIT показала нам, что большинство серьезных западных CMS (и коробочных и внутренних платформ) используют XML/XSLT в качестве единого унифицированного стандарта. Все-таки, российский IT-рынок по скорости внедрения новых технологий слегка отстает от западного. На этом фоне говорить о том, что XSLT — отстой, пока весь мир его использует, не совсем полезно и правильно.

    Поэтому я, зарегистрировавшись на Хабре, начну с попытки реабилитации несправедливо обиженного XSLT. На мой взгляд, ответственность участников рынка CMS как раз в том, чтобы продвигать современные технологии и быть своеобразными технологическими флагманами. А не дискредитировать их, даже если не получилось реализовать у себя или не нравится. Можно не читать тем, кто и так знает про XSLT или даже использует. Эта статья для тех, кто еще не в теме или сомневается. Тех, кто не согласен — прошу не устраивать холивар. Все имеют право высказывать свое мнение.

    Шаблонизаторы XSLT, Smarty и внутренние tpl коробочных CMS.


    Все технологические преимущества XSLT основаны на основной концепции, заложенной в него, — полное разделение бизнес-логики и логики представления. Смешать модели представления и модели бизнес-логики – это смертный грех программиста. И только человек с очень низкой квалификацией с этим не согласится. При этом, например, достаточно популярный шаблонизатор Smarty, не только позволяет реализовывать бизнес-логику в шаблоне, на уровне представления, но и подталкивает разработчика к этому, искушает его быстрым решением сиюминутной задачи. К чему это приведет впоследствии – к неструктурированной цепочке связей между шаблонами и скриптами, которая нарастает как снежный ком и в итоге становится неуправляемой. В итоге изменение, например, одного метода, который используется в шаблоне, приведет к тому, что «упадет» весь шаблон.

    Любые задачи по расширению становятся сравнимы с «написанием всего с нуля» даже для того разработчика, который изначально вел проект. Не говоря о том, что становится невозможным передача этого проекта другому разработчику. Таким образом, преимущества использования отчуждаемой CMS могут отчасти нивелироваться использованием Smarty, так как в сложном и тем более нестандартном внедрении он делает созданный проект неотчуждаемым от своего разработчика. Смена разработчика в большинстве случаев будет означать то самое «переписывание с нуля», которое, как ни парадоксально, в этом случае окажется более выгодным, чем трудозатраты на изучение «чужого» кода. Очевидно, что это решение не оптимально, и повлечет за собой очередную порцию достаточно существенных финансовых вливаний.

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

    Также нельзя не отметить незащищенность «от дурака», если в CMS используется Smarty – внедренец невысокого уровня «с помощью» Smarty может легко прямо в шаблоне прописать запрос к БД и обрушить всю систему целиком.

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

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

    10 аргументов в пользу XSLT


    Надежность технологии

    1) XSLT — это давно появившийся индустриальный стандарт, поддерживаемый W3C. Он разрабатывается многочисленной командой профессиональных разработчиков. Технология постоянно улучшается и обновляется за счет качественной поддержки. Во всем мире XSLT уже давно воспринимается как стандарт верстки, в России он используется на таких крупных проектах как Яндекс, Мой Круг и других.
    Безопасность

    2) Жесткое разделение бизнес-логики и модели представления данных ни при каких обстоятельствах не позволит верстальщику «убить» всю систему, если он имеет доступ только к шаблонам.

    Гибкость

    3) XSLT позволяет повторно использовать результаты уже произведенной работы. Единожды сверстанный на XSLT шаблон не держит на себе функциональность бизнес-логики и ее отработки, поэтому он свободно масштабируется и переносится на другие проекты.

    4) Для типовых операций достаточно создать шаблон только один раз и использовать его из проекта в проект. Пример из практики: студия-партнер получила заказ на разработку 3-х сайтов автосалона под различные марки автомобилей. На создание первого сайта у нее ушло около 2-х месяцев, второй сайт с учетом новых доработок был разработан за 1 месяц, третий сайт был поднят за 2 недели. Благодаря тому, что собственно технология уже сделана, сайты остается только «разукрасить» (т.е. сменить дизайн). Единожды решенная задача, в следующий раз требует в 2-3 раза меньше времени даже с внедрением новых функций.
    Доступность, понятность, невысокая стоимость разработки

    5) По нашему опыту, верстальщику, знакомому только с HTML и CSS, время разработки проекта на XSLT с нуля составит в среднем около месяца-полутора. При этом если он занимается изучением XSLT в отрыве от других задач по проектам, то может освоить его за полторы недели. Для сравнения – освоить tpl-шаблонизатор конкретной CMS такой же верстальщик сможет в среднем за неделю, а освоение в процессе работы над проектом займет у него тот же месяц. Но XSLT верстальщику нужно освоить только один раз, а каждый отдельный tpl-шаблонизатор тянет за собой отдельное изучение. Поэтому уже после разработки первого проекта на XSLT можно говорить об экономии на этапе внедрения.

    Отчуждаемость

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

    Расширяемость

    7) Правка XSLT шаблона не предполагает вмешательства в бизнес-логику и анализ структуры связей, которые могли бы использоваться в шаблоне будь он на Smarty. Поэтому, например, изменения в бизнес-логике не приведет к обрушению других шаблонов. В этом уже заложены возможности для последовательного расширения, так как все связи структурированы и поддаются модификации. Расширяемость при таком подходе становится гораздо менее трудозатратной, и снова снижается стоимость владения проектом.

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

    8) Некоторые задачи, решаемые в XML+XSLT просто и эффективно, представляются как минимум нетривиальными без XSLT.

    Например, с помощью XSLT можно строить децентрализованные сервисы (в частности, популярный в контексте Веб 2.0 mash-up), можно использовать для построения кластерных систем (конечно же, это не касается CMS). Обмен контентом с другими ресурсами на основе XML-формата позволяет использовать чужие сервисы на собственном сайте. При этом если этот сторонний сервис «ляжет», то с сайтом ничего не произойдет – данные могут браться из КЭШа какое-то время, а потом может перестать отображаться именно этот сервис при остальной работоспособности сайта в целом. Описанный выше подход Smarty благодаря развитым и неструктурированным связям с великой долей вероятности поспособствует тому, чтобы вместе с тем самым сторонним сервисом «лег» и весь сайт целиком.

    Нативная поддержка XML

    9) Изобилие данных в формате XML, которые часто нужно использовать в проекте, — это наша реальность. XSLT- шаблонизатор является «родным» парсером для XML, а все остальные решения – «велосипед».

    Производительность и скорость работы

    10) Один из «недостатков», которые ставятся некоторыми разработчиками в «вину» XSLT — то, что он не может решить задачи бизнес-логики. Сложно представить себе более абсурдное утверждение. В этом смысле накладывать базу данных на XSLT и требовать высокой скорости работы – такой же абсурд, как воспроизводить диск с поддержкой 5.1 через динамик обычного телевизора и требовать при этом Dolby Surround. XSLT по определению не должен этим заниматься, он создан только для того, чтобы реализовывать представление. А вот бизнес-логика должна подготовить те данные, которые ему нужны, чтобы отобразить страницу. И если она их подготовит, то о скорости работы XSLT вопросов возникнуть не может, потому что передавать нужно только то, что будет отображаться на странице (в большинстве случаев 10-50 товаров). Если делать полное преобразование базы на 10 тыс. товаров в XML, а потом на это накладывать XSLT-трансформацию, то результаты производительности будут весьма печальны. При этом будет полностью изнасилована концепция разделения бизнес-логики и представления, на которой основан XSLT. Неудивительно, что при подходе, описанном у Сергея Рыжикова, он не покажет чудес производительности и скорости.

    О недостатках XSLT.


    К сожалению, идеальных людей/продуктов/технологий не бывает. XSLT не исключение.

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

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

    Выводы.


    Для начинающего разработчика разобраться с tpl-шаблонами часто проще. Но на определенном этапе развития проекта использование XSLT становится оправданным как с технологической, так и с экономической точки зрения. Поэтому необходимо давать разработчикам выбор между tpl и XSLT. Но самим разработчикам необходимо понимать, что прогресс неизбежен и массовое распространение XSLT – это вопрос времени. Весь мир пошел этим путем и игнорировать его не стоит. Поэтому чем раньше разработчики начнут осваивать XSLT, тем больше денег заработают в будущем.
    Поделиться публикацией
    Комментарии 206
      +3
      1. В целом, согласен, что применение XSLT — это шаг вперед.

      2. Слова же о невозможности отчуждения проектов, в которых использован Smarty, видятся мне спорными. Здесь как кто напишет. Есть культура программирования в фирме — напишут нормально. Нет культуры программирования — и бизнес-логику с представлением смешают, и кучу врапперов к врапперам врапперов напридумывают :) С другой стороны, XSLT дисциплинирует и способствует снятию большого количества геморроя для директора студии в будущем, когда штат программеров, работавших над каким-то давним сайтом, ротируется, а исправления или дополнения в таком проекте приведут к потерям оплачиваемого рабочего времени на разборки с кодом и бакгфиксы к багфиксам.

      3. Наконец-то стали говорить о производительности XSLT и адекватности применяемых решений. Давно ждал, кто же ответит Сергею Рыжикову на его слова ( ага, кто бы говорил :-) ) про "низкую производительность" и "требования к отдельному серверу".
        +2
        Леша, ты бы лично стал разбирать чужой код на Smarty? Особенно, если тот, кто его писал не отвечает на звонки и письма?

        Я не говорю, что Smarty плохой, я говорю о его недостатках ;)
          0
          Стал бы или нет? Ну это зависит от ситуации. Воможно, был бы вынужден :-)

          Проблема с неотвечанием на звонки и письма очень знакома, особенно если с фрилансерами работать. Потому стараемся давать людям некоторые стандарты кодирования, смотрим их код перед тем, как решить, работать ли с ними.
            +1
            так вот, а в случае XSLT ты бы вообще так не парился - искать автора или разбираться в его коде самому.
            преемственность кода XSLT от разработчика к разработчику выше на порядок - это и есть отчуждаемость
              0
              В общем, да. Как я и сказал, XSLT дисциплинирует :)
                +2
                а разве на XSLT нельзя "нафигачить" так, что потом сторонний разработчик не разберется?
                мне не понравилось редактировать шаблон vBulletin, пусть он даже более структурированный. со Smarty в Shopscript я быстрее разобрался, хотя и там тоже было написано кривыми руками.
                а в минус XSLT не идет огромный размер шаблона?
                  0
                  везде можно "нафигачить"
                  у меня был опыт с точностью до наоборот, переход с одного языка на другой всегда влечет за собой подобный эмоциональный дисбаланс
                  а кто заставляет все пихать в один шаблон?? вы плохо знакомы с XSLT
                    0
                    шаблоны можно разбивать. и нужно.
                    и использовать повторно. например отдельный шаблон для генерации типичных форм. а если сделать правильно все - то многие шаблоны от проекта к проекту вообще редактировать не нужно будет - все представление будет менять при помощи цсс.
                    но это все требует "вгружения" в технологию, т.к. XSLT имеет принципиально иную идеологию нежели тот же Smarty...
                      0
                      чтобы не писать xslt-файлы огромных размеров можно пользоваться директивами xsl:import & xsl:include. если правильно использовать технологию(xslt), то очень гибко и удобно получается. уже около 3-х лет работаю с ней и всегда какие-нибудь нюансы узнаю.
                        0
                        «нюансы до сих пор» — эт что, плюс? :)
                          0
                          очень редко встречаются задачи в которых на 100% разбираешься с технологией во время решения задачи. просто задача требует только части знаний о какой-то технологии. xslt — не исключение.
                            0
                            Кхе. Я некоторое время назад, признаться, погружался уже в эти края. Не для веба, нет, применение было более хитрое.

                            Лезть в холиворы не стану, но и применять технологию нигде тоже не собираюсь больше :)
                    0
                    Это не совсем верно. С XSLT тоже можно "попариться", особенно если он был написан криворуким верстальщиком. Испытано на своем опыте.
                  0
                  всё таки, хоть и не говорите, но подтекстом таки чувствуется "смарти плохой"
                  то же самое, что говорить - пхп плохой
                  давайте сразу тогда писать на руби? :-)
                +1
                хм, а я вот склонна согласиться с Сергеем Котыревым относительно Смарти. Допустим, сайт делает не студия со штатом разработчиков, а фрилансер. Потом нам сайт надо модернизировать, приукрасить, в общем, заняться тюнингом проекта. Далеко не всегда есть возможность обратиться к "отцу" сайта - первому разработчику. А пригласите Вы другого, он скажет: "Э, нет, друг! Тут все нафиг надо переписывать, переделывать и вообще - все не по уму". Имхо, внушительный счет на N-ное количество килобаксов заставить помянуть Смарти не слишком добрым словом. К сожалению, таких историй море, так что вопрос целесообразности использования ХСЛТ актуален. Только где вот программеров XSLT-шных брать - вот в чем вопрос?
                  0
                  Изначально я хотел, чтоб у нас в продукте появилась поддержка Smarty. И вопрос кадров меня больше всего останавливал, когда наши девелоперы стали убеждать меня в преимуществах XSLT против Smarty. Они меня переубедили тогда.
                  И вопрос специалистов оказался решаемым - все три человека, которые сейчас занимаются XSLT у нас в офисе, все пришли без знания оного. Средний срок обучения - один месяц.
                    0
                    Воспитывать из верстальщиков. Из одаренных и любопытных.
                    В моей практике встречались такие технологи, которые из верстки ушли в серьезный Ajax или в программинг на Flash. Также может получиться и с XSLT. Был бы спрос - а любопытные и прогрессивные найдутся.
                    Плюс еще момент, который мне кажется важным... Есть разные уровни подготовки, которые востребованы для разных задач. То есть для какого-то сложного проекта нужен именно XSLT-программист (разработка модулей, шаблонов и т.п. с нуля), а для более простых проектов будет достаточно технолога, который просто использует уже готовые решения.
                    XSLT-программеры сейчас в дефиците, а технологов можно подготовить.
                      +1
                      на самом деле это суперская идея.
                      студии могут делать однотипные по функционалу проекты на одних и тех же шаблонах и при этом это будут разные сайты (в разных дизайнах и компоновках).

                      у нас один партнер однажды собрался сделать около сотни разных сайтов для одного клиента на одной коробке - так он больше всех был рад xslt ))
                        0
                        а как это отражается на конечной стоимости проекта для заказчика?
                          0
                          по законам экономики и здравого смысла она снижается ;)
                            +1
                            Тссс! Она повышается за счет внедрения масштабируемости и унифицируемости:)
                              0
                              справедливости ради лучше сказать так:
                              она краткосрочно повышается за счет снижения скорости и повышения требований к квалификации,
                              но среднесрочно повышается за счет масштабируемости и унифицируемости
                        0
                        В свое время были в дефиците верстальщики на CSS. Но когда требования верстка на div является обязательным - люди начинают учится данной технологии - пускай даже и принудительно.
                        Лидеры рынка должны задавать правильный вектор развития технологий, что бы молодые специалисты понимали куда стремится - а не делать на том что проще изучить.
                        +1
                        С другой стороны, что мешает сказать то же самое XSLT-шнику? :))
                          +1
                          появление специалистов XSLT - вопрос времени. воспитывайте культуру. в том числе, уважение к заказчику и его деньгам. я отчасти им являюсь, и заинтересована в расширяемых и динамичных проектах.
                            0
                            Брать нас и учить :)
                            На самом деле я этой технологией заинтересовался года 3 назад, когда пытался написать свою CMS :)) точнее пришел к выводу что логика должна давать данные в XML и шаблон должен быть на XML и после нескольких попыток изобрести велосипед "наткнулся" на XSLT, я был очарован, но...
                            Но некоммерческих проектов не было, на коммерческих, сами понимаете, не мог сказать заказчику "можно, за 3 дня сделать на Smarty, но подождите 2 недели, я буду XSLT осваивать, еще, желательно, мне это время оплатить" :( попытки делал освоить XSLT в процессе, но заканчивались тем, что в авральном порядке на кофе и адреналине переводил все отображение на чистый php/smarty

                            Информации практически нет о XSLT, точнее о его практическом использовании, изобретать велосипед каждый раз нет возможности, исходников серьезных проектов никто не даст, конечно. По стандарту да справочникам только примитивные преобразования изучать. Популярные открытые CMS/CMF XSLT если и поддерживают, то не нативно, шаблонов рабочих вообще не найдешь под них, рускомьюнити, где помогли бы сделать шаг от хрестоматийных примеров к реальным системам тоже не обнаружил... Вакансий, где требуется начальные знания XSLT тоже минимум, по крайней мере в Питере - либо вообще не упоминают, либо хотят уже профессиональное знание и практические навыки эффективной работы...

                            так что так и остается использование XSLT недоступной мечтой, вроде и знаю что-то, и вывод данных страницы на XML только рад делать, и даже делаю, но потом их парсю в массивы и вывожу чрез что придется
                            +1
                            На мой взгляд забыли упомянуть, что XSLT давольно расширяемый язык, и тем кого не устраивают стандартные возможности - могут подключить дополнительные расширения для языка, написанные сторонними разработчиками (яркий пример расширения проекта http://exslt.org/).
                              0
                              Есьт ещё Apache FOP.
                              +4
                              Когда речь заходит о выборе той или иной технологии нужно абсолютно точно понимать что в любом случае тебе придется платить. Вопрос лишь в том - сколько? и за что? Любой инструмент призван решать конкретную задачу - отвертка закручивает винты, а молоток забивает гвозди.
                              У XSLT есть только одно слабое место, за которое так любят цеплятся его противники - производительность; и речь, зачастую, идет даже не о времени самой трансформации, а о лишнем шаге преобразования данных в xml, поскольку XSLT работает только с xml. Но я не слышал ни одного аргумента против XSLT с архитектурной точки зрения, потому что их нет. И я могу абсолютно точно сказать, не вдаваясь в детали, что в этом плане XSLT делает любой шаблонизатор, и тот, кто его использует, прекрасно знает за что он платит!
                              CMS, на мой взгляд, является универсальным средством создания сайтов, а значит должна позволять решать самые разные задачи, и для каждой конкретной задачи должна предоставлять необходимый инструмент, иными словами не только гвозди забивать, но и винты закручивать...
                              P.S. А еще есть чисто субъективные моменты, XSLT - красив!
                                0
                                Разговоры о низкой производительности XSLT вызваны у разных людей разными причинами:

                                1. Кто-то неправильно его применил (есть чудаки, хранящие в XML каталоги товаров) и закономерно получил тормоза.

                                2. Кто-то просто не умеет с ним работать (не смог реализовать в своей CMS), ему проще сидеть на смарти, а XSLT — дискредитировать.

                                3. Кто-то наслушался первых двух, а сам знаниями достаточными не обладает, но охотно ретранслирует чушь :)
                                  0
                                  1. Уж мне-то не надо говорить о неправильности его применения, я к данному внедрению имею вроде как не самое последнее отношение ) еще раз подчеркну речь даже не о самой трансформации, а о лишнем этапе трансляции данных в xml
                                  2. см. п.1
                                  3. см. п.1
                                    0
                                    технологии осваиваются после понимания их преимуществ. понимание приходит с опытом. опыт со временем.
                                    я сам в бизнесе веб-разработки с 2000 года, но еще полгода назад я бы не сел писать такую статью, т.к. сомневался.
                                    сейчас увидел, многое понял, посчитал, поумнел, написал.

                                    через месяц, полгода или год и остальные поймут потихоньку и начнут осваивать xslt. может даже Битрикс одумается.
                                      0
                                      как это ни странно звучит, но понимание недостатков приходит сразу вслед за пониманием преимуществ, а не наоборот; когда период опьянения от новой технологии проходит и взгляд становится более трезвым. В силу вступает холодный прагматизм и расчет. Тебе все еще нравится XSLT, но ты понимаешь что вокруг есть и другие)
                                      0
                                      Ну это не про Вас мой комментарий был :)
                                        0
                                        Почитал статью Рыжикова и офигел. Да и у вас то же самое - зачем перегонять данные в _текстовый_ xml файл (не совсем понял что вы имели в виду, но у Рыжикова именно так)? Там же написано - для того, чтобы прогнать по нему xml-парсер. Ужос. Кто мешал складывать данные сразу в дом-дерево? Ай да Рыжиков, ай да "шпециалист" :(
                                          0
                                          У меня тоже был легкий шок, хоть я не программист. :)
                                            0
                                            Складывать данные в DOM? Ну это когда данных немного и памяти достаточно. ;)

                                            Для разбора составного датасета в XML лучше применять какой-нибудь SAX-парсер, а не DOM.
                                              0
                                              Мы ведь всё ещё говорим о трансформации в хтмл страничку? Откуда и зачем там много данных?
                                              0
                                              бр-бр-бр… осмелюсь спросить, что такое dom-дерево, если не объектная структура и как ее передавать между независимыми компонентами? вот создал я на своем php dom-дерево и надо мне его послать другой программе, которая на это дерево натравит xslt-шаблон… мои действия могут быть следующими:

                                              * упаковать в xml
                                              * упаковать в иную сериализованную строку
                                              * упаковать в какой-нибудь бинарный формат, желательно понятный как php, так и libxslt

                                              что делать?)
                                                0
                                                Я не очень понимаю как это — создать на пхп дом-дерево и послать другой программе. Какой другой программе? Пхп — это язык для написания веб-фронтендов, разве нет? Отдельностоящие компоненты, написаные на пхп и передающие данные другим компонентам? Что могло сподвигнуть на выбор пхп в качестве основного языка для реализации такой архитектуры?
                                                Кстати, из ваших вариантов мне больше нравится второй.
                                                Если всё это крутится внутри одного аппсервера, разумеется (ну, или группы тесно взаимодействующих серверов). Если надо общаться с миром «извне», то, ясное дело, xml вполне.
                                                  0
                                                  Для XSLT-преобразований я хочу использовать nginx + xslt, у которого уже подгружены все необходимые шаблоны. Собственно, в каком виде иначе как в XML мне передавать ему данные от php? Промелькнула мысль «зачем в php упаковывать данные в xml, чтобы xslt-шаблонизатор его парсил, когда можно передать dom-дерево». Вот мне и интересно, как передать это самое dom-дерево)
                                                    0
                                                    А-а-а! Ну да, в таком виде, видимо, никак иначе :).
                                                    Мысль имела в виду, что xslt-трансформатор находится в пределах приложения. Я слегка в другой, относительно пхп реальности пребываю…
                                                    Но, даже в вашем случае, это ведь не совсем «xml-файл» получается. Скорее поток такой текстовый…
                                          0
                                          Кстати, о производительности — есть у nginx модуль для работы с xslt. Шаблоны парсятся при чтении конфигурации и затем натравливаются на выход с бакэндов или xml-файлов. Кто-нибудь пользовался?
                                          +4
                                          Smarty тоже достаточно расширяем. XSLT - хорошее решение, но не всегда его необходимо.
                                          Будте мудрее и думайте перед тем кк сделать выбор в сторону одного или другуго.

                                          P.S. Для нас оказался ближе Смарти.
                                          • НЛО прилетело и опубликовало эту надпись здесь
                                              +2
                                              Не крест, конечно же. Но для новичков, а также для управленческого состава статья Сергея Рыжикова вполне может служить причиной пагубного отказа от XSLT. Как же ж! Тормозит, дескать. Дескать, требует отдельного сервера.

                                              Хотя отдельного сервера требует, как раз, совсем другой продукт ;-)
                                                0
                                                По поводу статьи Б. Лично мной примерно так и воспринимается. В ней я прочитал, что в XSLT неэффективно делать вещи, которые в нем на самом-то деле и эффективны.
                                                Насчет выбора Smarty в качестве основного фигуранта данной статьи. Нужно же было кого-то выбрать. Тем более, что основная версия Б. все-таки на php.
                                                А в .NET'е XSLT - это уже стандарт де-факто, который компанией M$ продвигается. У моих .net'ских коллег факт использования чего-то кроме XSLT вообще вызывает сильное удивление.
                                                • НЛО прилетело и опубликовало эту надпись здесь
                                                    0
                                                    что это за причина #11?
                                                    • НЛО прилетело и опубликовало эту надпись здесь
                                                –1
                                                не понравилась статья, сплошное повторение избитых фактов о разделении логики, о реальной производительности ни слова
                                                  +1
                                                  В том то и дело, что производительность XSLT намного выше (это факт), но только при правильной логике.
                                                  Поэтому и "повторение избитых фактов о разделении логики", что бы люди понимали что дело не в XLST - а в не правильном его использовании.
                                                    0
                                                    приведите примеры, я тут ниодного примера не видел, только голословные утверждения
                                                      0
                                                      Примеры чего вы хотите тут увидеть сравнительные тесты обработки вывода как шаблонизатором так и XSLT? Это приведет к тому, что будут рассматривать уже шаблонизаторы и говорить, что у вас там шаболнизатор плохой а вот у нас он делает это быстрей. И в итоге отдалимся от тему статьи.

                                                      Как уже упоминалось что на западе XML/XSLT становиться уже де-фактом разработки CMS - это по вашему голословные утверждения?

                                                      То что все больше и больше крупных российских сервисов созданы на этой технологии - тоже голословные утверждения?

                                                      Для меня как для разработчика голословным утверждением является, то что XSLT тормозит и никуда не годнен.
                                                        0
                                                        отдалимся? нет, мы просто увидим что статья - мягко говоря не показывает всю полноту картины)))
                                                        нет, в это я готов легко и непринужденно поверить.
                                                        интересно, а на чем работает хабр?))
                                                        я такого не утверждал, у меня есть примеры сильно тормозящего xslt, но я не могу их предъявить - это закрытый код и мне он не принадлежит поэтому я хотел бы что бы кто-нибудь продемонстрировал сравнительный анализ по данному вопросу.
                                                        з.ы. iqeek (чуть ниже) - очень все правильно написал, вопрос ведь даже не в том тормозит/не тормозит - любые процессы кушают и проц и память, вопрос в том сколько это стоит в рублях и что дороже/дешевле
                                                          +1
                                                          Спорно :)

                                                          я могу не использовать рекурсию, а использовть xsl:for-each да еще и вложить и вдруг друга, а также паруз раз сделать match на корень документа для вытягивания каки-либо праметров - И У МЕНЯ ВСЕ ТОЖЕ БУДЕТ ТОРМОЗИТЬ.

                                                          Но это показатель того, что круворукий разработчик, а не XSLT плохой. :)

                                                          Ничего личного :)
                                                            0
                                                            Тоже самое и о Смарти. Почему-то когда говорят о смарти - обвиняют его а не криворукого программера. А когда говорят об XSLT то оно сразу не виновато в тормозах. Кривые программеры есть везде и технология тут не причем. Однако в статье Смарти в недостатки приписывались только кривые программеры. Я вот все думаю - что ж там такое в шаблоне должно быть чтобы надо было вызванивать программиста, а трагедией было бы что он не отвечает?
                                                              0
                                                              я не обвиняю Smarty - я защищаю XSLT как шаблонизатор, от людей которые не умеют им пользоваться :)
                                                    • НЛО прилетело и опубликовало эту надпись здесь
                                                        +3
                                                        выше чего?) и где засвидетельствован данный факт?

                                                        мне тут вспомнился один момент на ClientSide 2007, когда одного из докладчиков прямо в лоб спросили о производительности XSLT, докладчик как-то сразу замялся и не знал что сказать, тогда Надежда Строганкова взяла микрофон в руки и сказала фразу, которую я очень долго ждал: да, XSLT на порядок дороже по производительности чем перловские шаблонизаторы, но вы знаете за что вы платите. Вот и все, нужно просто понять за что вы платите...

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

                                                        Далеко не на всех проектах необходимо вести борьбу за каждую милисекунду, но даже на тех проектах где это жизненно необходимо, люди готовы расплачиваться производительностью, в обмен на что? Когда вы поймете за что вы готовы платить, вы будете платить!
                                                          0
                                                          >>выше чего?) и где засвидетельствован данный факт?
                                                          Как прасер XML - XSLT самый производительный :)
                                                            0
                                                            конечно, если у тебя уже есть готовый xml и тебе его нужно во что-то превратить то да, но речь идет о том что xml не нужен, а все шаблонизаторы работают с массивами)) в этом весь и фокус... Отсюда, якобы, их быстрота, с чем конечно сложно спорить, но и в этом же их неудобство
                                                            0
                                                            как не странно но на том же ClientSide 2007, в секции шаблонизаторов был только XSLT

                                                            а вообще нужно понимать за что вы платите и что вы эконовите, в случае XSL вы платите больше за серверные ресурсы, но при этом сокращаете затраты человеческого времени на разработку и поддержку
                                                        0
                                                        А почему не рассматривается вопрос о том, что XML/XSLT шаблоны в коде весит намного больше, чем какой-то специализированный шаблонный движок, что приводит в конечном счете к увеличению количества и размера файлов проекта, увеличению времени на разработку и тестирование.

                                                        > В свое время были в дефиците верстальщики на CSS.
                                                        верстка по стандартам с использованием CSS приводит как раз к уменьшению кода и затрат на его сопровождения
                                                          0
                                                          1) XSL шаблон не настолько больше весит, а при правильном проектировании может весить и меньше
                                                          2) XSL просто читается что повышает скорость его чтения
                                                          3) XSL хорошо структурирован, что позволяет просто навигироваться даже в большом шаблоне
                                                          4) увеличение размера шаблона лишь косвенно может увеличить время на разработку
                                                          5) XSL есть практически везде, что позволяет использовать XSL разработчиков практически во всех задачах требующих отображения данных, начиная от построения отчетов заканчивая сложными JavaScript приложениями что сокращает расходы
                                                          6) XSL можно накладывать на клиентской стороне, что сильно экономит серверные ресурсы и снижает расходы на эксплуатацию проекта
                                                            0
                                                            1 - Пример в студию
                                                            2 - А что , тимплейтные движки делаю что-то другое?
                                                            3 - ГРАМОТНЫЙ шаблон В ЛЮБОМ движке читается легко и прост для навигации
                                                            4 - по-моему, как раз таки прямо увеличивает.
                                                            5 - HTML тоже есть везде, а еще везде есть текстовые файлы :) . Не аргумент. Сложные JS приложения используют на XSLT а xml, и то не особенно удачно (повреждение при передаче = ошибка).
                                                            6 - Увеличение трафика и убийство слабой техники пользователями.
                                                              0
                                                              1) давайте пример данных, я вам приведу пример реализации
                                                              2) я имел в виду разработчиков
                                                              3) вот именно что грамотный, только вто зачастую качество девелопмента страдает...
                                                              4) обоснуйте
                                                              5) и что для каждого языка теперь учить новый шаблонизатор?
                                                              6) в ряде случаев это не увеличение, а снижения трафика + что вы понимаете под словом слабой?
                                                                –2
                                                                1- Пример предоставляет доказующая сторона. Иначе - голословные утверждения ;)
                                                                2- Возможно, дело привычки
                                                                4- Увеличение размера шаблонов -> увеличение времни проектирования, отладки и тестирования -> увеличение стоимости работы
                                                                5- В очень редких случаях. Сложное форматирование, большие объемы данных - это верный путь к увеличению. Слабые машинки : 512 Мб ОЗУ, процессор 900Мz


                                                                Ладно, есть предложение завершить холивар. Мне не переубедить Вас, Вас - мне. Всякой технологии свое место и время.
                                                            0
                                                            размер файла никак не связан со временем разработки и тестированием.
                                                            если Вы вместо длинных имен переменых будете использовать короткие, Вы уменьшите размер файла, но увиличите время на разработку и тестирование.
                                                            По этому нельзя так категорично утверждать.
                                                            XSLT, в силу синтаксиса XML, но в этом его и плюс, шаблон можно провалидировать.
                                                              0
                                                              про производительность - нигде я не имел ввиду, что скорость рендеринга/парсинга/передачи XSLT меньше, чем какого-то движка (вопрос не об этом), я говорил только о скорости написания-отладки-изменения таких шаблонов программистом. Есть у меня проект написанный с использованием XSLT, так вот добавление обычно занимает по времени раза в 2 - 4 больше, чем для обычного движка, где можно вставить <%= item.rating %>, при этом откуда идет item.rating и я прекрасно знаю и следующий девлопер будет знать .... а вот реальный код оттуда (сходу его не разобрать)
                                                              <xsl:template name="rate_big">
                                                              <xsl:param name="already_rated"/>
                                                              <xsl:choose>
                                                              <xsl:when test="already_rated = '0'">
                                                              <xsl:choose><xsl:when test="($iteration < 6)">
                                                              <div id="rate_{$iteration}" class="rating" onclick="xajax_r({$iteration},{id});return false;"><span class="hidden">*</span></div>
                                                              <xsl:call-template name="rate_big">
                                                              <xsl:with-param name="iteration" select="$iteration + 1"/>
                                                              <xsl:with-param name="already_rated" select="$already_rated"/>
                                                              </xsl:call-template>
                                                              </xsl:when></xsl:choose>
                                                              </xsl:when>
                                                              <xsl:otherwise>
                                                              <xsl:choose><xsl:when test="($iteration < 6)">
                                                              <div id="rate_{$iteration}" class="rating"><span class="hidden">*</span></div>
                                                              <xsl:call-template name="rate_big">
                                                              <xsl:with-param name="iteration" select="$iteration + 1"/>
                                                              <xsl:with-param name="already_rated" select="$already_rated"/>
                                                              </xsl:call-template>
                                                              </xsl:when></xsl:choose>
                                                              </xsl:otherwise>
                                                              </xsl:choose>
                                                              </xsl:template>

                                                              форматирование фигачится :( ... на мой взгляд код сложный, потому что он не позволяет встраивать код на php/ruby/perl/asp.net
                                                                0
                                                                а сколько времени займент изменение шаблонов когда проет перейдет с ASP.net на php?
                                                                судя по вашему примеру (изобилию call-template/with-param), вы не совсем поняли как писать на XSLT
                                                                  0
                                                                  > судя по вашему примеру,… вы не совсем поняли как писать на XSLT
                                                                  +1 =)
                                                                  0
                                                                  а сколько времени займет изменение шаблонов когда проект перейдет с ASP.net на php?
                                                                  судя по вашему примеру (изобилию call-template/with-param), вы не совсем поняли как писать на XSLT
                                                                    0
                                                                    > судя по вашему примеру (изобилию all-template/with-param), > вы не совсем поняли как писать на XSLT
                                                                    можно альтерантивный вариант

                                                                    > а сколько времени займет изменение шаблонов когда проект > перейдет с ASP.net на php?

                                                                    пока для меня стоит вопрос так - сайт с большим количеством XSLT понимать сложно и дорабатывать тоже сложно (много времени уходит), при этом простые шаблоны понимаются легко, а сложные шаблоны не публикуются
                                                            • НЛО прилетело и опубликовало эту надпись здесь
                                                                0
                                                                я написал в начале статьи, что ее цель не научить вас на конкретных примерах, а скорее заинтересовать вас самих научиться.

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

                                                                  // желательно чтобы буквы были видны
                                                                    0
                                                                    скринкасты снимем. осталось выбрать story.

                                                                    ps. буду рад вашим предложениям )
                                                                      0
                                                                      зырь в title 8-)
                                                                  • НЛО прилетело и опубликовало эту надпись здесь
                                                                      0
                                                                      в том то и дело что у смарти есть привязка к PHP, и если у вас в команде есть верстальщик который знает смарти то что бы он сделал шаблон к примеру для сервера на JAVA или C++ или чего угодно ему нужно учить новый шаблонизатор

                                                                      а XSL верстальщик может сделать шаблон к любому бекенду, даже не особо задумываясь какие технологии там используются, есть лишь небольшие различия в различных диалектах XSLT процессоров
                                                                        0
                                                                        Любая универсальность есть жертва функциональности и скорости.
                                                                          +2
                                                                          время хорошего разработчика зачастую стоит дороже железа, так что на с экономненные деньги можно купить более мощное железо.

                                                                          так что унификация не всегда приводит к потерям в скорости.
                                                                            0
                                                                            Глупо решать проблему быстродействия новым железом. На примере myspace можно понять что это не решение.
                                                                              0
                                                                              1) XSL не на столько медленнее
                                                                              2) фронтенды которые занимаются шаблонизацией просто и эффективно кластеризуются
                                                                                0
                                                                                Пример крупного проекта с большой нагрузкой пожалуйста на базе XSL.
                                                                                Не думаю, что в MySpace и т.п. проектах до такого не додумались. Или Вы гений или тут есть свои подводные камни.
                                                                                  0
                                                                                  практически все:
                                                                                  *.yandex.ru
                                                                                  *.ya.ru

                                                                                  ЗЫ
                                                                                  конкретные проекты лень перечислять
                                                                                    0
                                                                                    Не показатель. Там не на 100% все на XSLT, используются гибридные решения (информация 1.5 летний давности, возможно уже и поменялось-что-то)
                                                                                    http://phpclub.ru/detail/article/2002-05…
                                                                                    "проект соответствующего масштаба (мелкий можно и в виде HTML смешанного с PHP, для крупного XSL тоже не очень подходит)"
                                                                                      0
                                                                                      ок приведу конкретно:
                                                                                      ya.ru
                                                                                      market.yandex.ru
                                                                                      fotki.yandex.ru

                                                                                      три крупных проекта, и все используют во фрондендах XSL
                                                                                        0
                                                                                        А можно что-то не от Яндекса?
                                                                                        P.S. дайте ссылка на материалы где написано "Яндекс - это 100% XSLT"
                                                                                          0
                                                                                          не яндекс: soft.oszone.net

                                                                                          яндекс это не 100% XSL (есть вещи где нету XSL, к примеру на морде www.yandex.ru)
                                                                                            0
                                                                                            10К в день.. не особо нагруженый проект.
                                                                                            Хм, в поиске явно прописаны сыслки - PHP.
                                                                                            Дезинформация какая-то ;)
                                                                                              0
                                                                                              пример в тему: PHP + шаблонизатор на XSL, так что это ни какая не "Дезинформация"

                                                                                              пример среднего размера, примеров с большой посещаемостью испрользующих XSL под рукой нету
                                                                                              0
                                                                                              Ну. там шаблончик то очень примитивный, как я вижу из кода странички.
                                                                                                0
                                                                                                1) в чем заключается его примитивность?
                                                                                                2) почему шаблон не должен быть примитивным? это веть на оборот хорошо!
                                                                                                  –1
                                                                                                  Повторяю - "пример крупного проекта с большой нагрузкой пожалуйста на базе XSL."
                                                                                                  Вам выдержку дать определение понятия "крупный проект" или "большие нагрузки"?

                                                                                                  П.С. Думаю, надо заканчивать холивар. Спасибо за диалог. Удачи Вам в Ваших проектах.
                                                                                                    0
                                                                                                    Уймитесь, о Священные Воины!
                                                                                                    Безусловно, очень трудно пытаться доказать, что Яндекс Фотки - проект с большой нагрузкой, если вы не желаете в это верить.
                                                                                                    Так стоит ли пытаться доказывать что-то? ;)
                                                                                                      –2
                                                                                                      Да уже все утихло.
                                                                                                      А на счет Яндекс Фотки - я уже говорил, Яндекс использует комплексные решения, на сколько я знаю. Как и всякая крупная компания там умеют применять микроскопы по делу :)
                                                                                                      И вообще,я просил примеры других компаний.
                                                                                              0
                                                                        0
                                                                        Ну, форматтеры даты и всяческие эскейперы скорее всего уже есть на exslt.org. Вот с передачей массивов/объектов в шаблон уже сложнее — это нельзя, ЕМНИП. Хотя, скорее всего я чего-то об этом не знаю.
                                                                          0
                                                                          Память вещь такая :)

                                                                          <xsl:stylesheet version="1.0">

                                                                          <xsl:variable name="имя_переменой" select="какое-то XML дерево" />

                                                                          <xsl:template match="/">
                                                                          <xsl:apply-templates select="$имя_переменой" /> <- и делай там что хочешь
                                                                          </xsl:template>
                                                                          <xsl:template match="что-то">
                                                                          <xsl:apply-templates select="$имя_переменой" /> <- и опять же делай там что хочешь
                                                                          </xsl:template>
                                                                          </xsl:stylesheet>
                                                                            0
                                                                            Я не спец в данной области, я только учусь — использую вот тут, которое пока еще не закончил, кстати.
                                                                            Так вот, если я правильно понимаю, то извне в шаблон (как параметр абстрактной ф-ции TransformIt) можно передавать только значения примитивных типов/строки(?). Или, как максимум, DOMFragment/DOMDocument. Я правильно понимаю текущую ситуацию?
                                                                            Или же все параметры, используемые шаблоном, мне следует впечатывать в этот шаблон либо напрямую, либо используя xsl:include/xsl:import? Спасибо.
                                                                              0
                                                                              nod-set в нутри переменной появился официально только в XSLT 2, для первой версии это только в расширениях, в стандарте XSLT 1 этого нет!
                                                                          +2
                                                                          "Отладка шаблона на XSLT, если в нем допущена ошибка, может потребовать от разработчика существенных усилий по ее нахождению и устранению. При этом даже любой незакрытый тег ведет к неработоспособности всего шаблона. Поэтому XSLT требует от разработчика особой тщательности, аккуратности и внимательности к деталям."

                                                                          - а как же дебаггеры XSLT, которые есть и в Visual Studio, и для Eclipse?
                                                                            +1
                                                                            именно так!
                                                                            при использовании таких инструментов, как Eclipse проблем возникать не должно, и обычно не возникает.
                                                                            но есть любители все редактировать через far+colorer. у них иногда возникают проблемы при командной работе.
                                                                              0
                                                                              Ясно, спасибо :)
                                                                                0
                                                                                должен заметить что debug, если имеется ввиду именно debug, а не банальная проверка синтаксиса, в XSLT пока еще на порядок хуже и затруднительнее, чем в других языках...
                                                                                лично я ушел от Eclipse к простому и легкому TextWrangler/XSLPalette, в котором даже проверки синтакcиса нет, я не люблю избыточные среды, если в них нет необходимости, и в большинстве случаев никакой xslt-debugger, не убережет вас от ошибок лучше чем собственная голова, как говорится - на debugger надейся, а сам не плошай)
                                                                              +1
                                                                              По моему мнению Smarty по сравнению с XSLT банальная отрыжка разработчика…
                                                                              Имею опыт работы с обеими системами и от XSLT как и от всей технологии XML испытываю нескончаемое удовольствие, снимает множество головных болей.
                                                                                0
                                                                                ну это уже холиварщина ;)
                                                                                Smarty предпочтителен в небольших, неотчуждаемых и не развивающихся проектах.
                                                                                Большинство проектов Рунета сейчас именно такие. Просто хочется это менять...
                                                                                  0
                                                                                  Да, знаю я что холиварщина ) Но согласитесь XSLT есть за что любить.
                                                                                  А вам лично большое спасибо за то что подняли тему.
                                                                                    0
                                                                                    почему?
                                                                                  +4
                                                                                  Приходилось учавствовать в разработке довольно известных CMS, одна работала с XSL, другая с обычными шаблонами. Как одна фирма, так и другая занимаются, помимо разработки CMS, еще и разработкой сайтов на своих системах.
                                                                                  Так вот подход, применяемый в фирме, где система с XSL такой, что имеется законченная коробочная версия продукта, и на базе неё уже делается сайт. Все фичти реализуются "легальными способами", т.е. код системы (ядро, модули) не меняется, меняются только XSL шаблоны и специальные скрипты.
                                                                                  Во второй же системе, постоянно, под каждый проект, приходилось дорабатывать модули, а то и ядро, т.к. многие вещи обычными шаблонами просто не реализуешь, нужно было дописывать методы, исправлять существующие.
                                                                                  XSL же позволяет вынести часть логики непосредсвенно в шаблон.

                                                                                  Почему большенство наших производителей CMS против XSL - яснее ясного. Кому хочется ломать и строить заново уже устоявшийся механизм, который стабильно приносит $?
                                                                                    0
                                                                                    Дело не в технологии, а прямоте рук.
                                                                                    0
                                                                                    Еще "недостаток" XSLT в том, что программисты не сразу понимают его, ведь в нем не процедурный подход к программированию.
                                                                                    Я считаю что это лучший шаблонный язык на сегодняшний день.
                                                                                      0
                                                                                      есть мнение что он не для программистов, а для верстальщиков... но язык действительно уникальный, непохожий ни на один другой, чтобы проникнуть в его суть программистам придется развернуть свой мозг в другую сторону
                                                                                        0
                                                                                        XSLT - это НЕ шаблонный язык. Это XML, позволяющий делать из одного XML другой XML.
                                                                                        Чтоб эффективно использовать XSLT в качестве языка шаблонизации, нужно включать голову на обоих концах процесса. Поскольку изначально технология создавалась не для этого.
                                                                                          –1
                                                                                          Ну скажем так - это одно из применений этого языка, которое положит на лопатки любое другое решение в этой области. А голову надо всегда включать.
                                                                                        • НЛО прилетело и опубликовало эту надпись здесь
                                                                                            0
                                                                                            > Это не шаблонный язык вообще.
                                                                                            ок. из xslt: тег-инструкция "xsl:template". как переводится слово "template"?
                                                                                            • НЛО прилетело и опубликовало эту надпись здесь
                                                                                              0
                                                                                              1) группировка с сортировкой тривиальна, лично для меня таковой планкой полное понимание механизма группировки мюнха.
                                                                                              2) кому как
                                                                                              3) кто ищет тот всегда найдет, есть люди которые активно делятся своим опытом и помогают у обучении новичкам
                                                                                              4) чем вам качество не угодило?
                                                                                              • НЛО прилетело и опубликовало эту надпись здесь
                                                                                                  0
                                                                                                  из глюков я встречал только два (в Saxon):
                                                                                                  1) for-each-group груп не работает со сложным группировочным XPath выражением
                                                                                                  2) for-each-group не умеет разбивать блоки текста в группы по br

                                                                                                  скорость у XSL нормальная, вот к примеру у меня есть небольшой сайт (примерно 3100 страниц) (для экспериментов по обработке данных) он собирается из одного XML файла (15мб) одним XSL преобразованием примерно за 21с, собирается саксоном, а он не самый быстрый XSL процессор.

                                                                                                  думаете на PHP + смарти было бы быстрее?
                                                                                                  • НЛО прилетело и опубликовало эту надпись здесь
                                                                                                      0
                                                                                                      иногда я накладываю XSL на файлы более 200м, там каждый процент производительности важен... а других способов решить задачу просто нету, вот по этому и спрашивал.

                                                                                                      я не говорю про то что PHP медленный, я говорю что XSL достаточно быстр
                                                                                            0
                                                                                            Отмечу, что, расписывая недостатки Smarty, автор статьи не упомянул о реализованной в нём возможности запрета напрямую обращаться к PHP. Детский сад, имхо: "а в Smarty можно запрос к БД в шаблоне прописать", "а в XML можно каталог товаров запихнуть и всё затормозит"... Так сдуру-то можно и сами знаете что сломать :) На мой взгляд, тема в статье раскрыта чересчур однобоко.
                                                                                              –2
                                                                                              А в XSLT есть возможность, наоборот, разрешить прямое обращение к PHP :) Так что да, сдуру можно сломать что угодно.
                                                                                              +6
                                                                                              Идея правильная, поддерживаю. Действительно, слышал много чего плохого об XSLT, а потом оказывалось, что мнение сформировано не на основе собственного опыта, а по прочтении упомянутой статьи от битриксоидов.

                                                                                              Однако, не со всеми аргументами могу согласиться.

                                                                                              Разделение логики и представления, вообще-то, зависит не только от технологии, но и от просветленности кодера. Умный кодер сделает все как надо хоть на смарти, хоть на шаблонах от phpBB. Глупый кодер и в XSLT такой лес нагородит, что проще будет застрелиться, чем понять полет мысли. Хотя, так уж исторически сложилось, что у нас люди, овладевшие XSLT, в среднем по больнице имеют более высокую квалификацию. Но это - не преимущество технологии. А часть приведенных пунктов, как мне кажется, выдают преимущества подхода "отделяй и влавствуй" за преимущества самого XSLT.

                                                                                              "Безопасность" - притянута за уши, ИМХО. В первую очередь, не следует допускать идиотов до кода, вне зависимости от технологии идиот накосячит. А если вдруг верстальщик действует не по глупости, а из вредительских побуждений - тем более не проблема все испортить - матерное слово в шаблон вставить, например :)

                                                                                              "Нативная поддержка XML" - не совсем в тему. Когда стоит задача преобразования уже предоставленного XML (например, полученного от некоторого удаленного сервиса) - разумеется, XSLT будет оптимальным вариантом, он для этого и сделан. (При этом XSLT-процессор НЕ является "родным парсером XML", как сказано в статье. XSLT делает из одного XML другой XML, и все. Например, распарсить конфиг и передать данные в приложение XSLT не может). В роли средства преобразования XML-документов XSLT не нуждается ни в какой реабилитации. Но к использованию XSLT в качестве шаблонизатора в CMS/CMF это не имеет отношения.

                                                                                              Полутора недель на освоение XSLT, разумеется, не достаточно. Хотя там всего-то десяток употребительных конструкций. Через полторы недели, как правило, верстальщик начинает писать код "как-на-смарти". Ну или как на PHP. Один шаблон, пачка вложенных for-each, ветвление через choose где ни попадя, дублирование кода и прочие радости. Много раз такое видел.

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

                                                                                              С другой стороны, использование XSLT предполагает специфическую "инфраструктуру" приложения, а именно - представление документа в виде XML-дерева. От того, как выполняется это действие, многое зависит, здесь есть как большие преимущества, так и большие грабли.

                                                                                              Есть еще пара важных моментов, про которые в статье не сказано.
                                                                                              Во-первых, XML-документ является для верстальщика гораздо более наглядным представлением данных, с которыми он должен работать. Согласитесь, XML можно распечатать, изучить, разобраться в деталях. ИМХО, это гораздо лучше, чем убогая консоль smarty ;) При этом верстальщик понятия не имеет о внутреннем устройстве объектов в приложении. Он видит ТОЛЬКО данные.

                                                                                              Во-вторых, связка XML/XSLT _действительно_ кроссплатформенна. Можно переписать весь проект на другом языке программирования, не трогая при этом ни строчки в шаблонах. А можно отдать трансформацию целиком на клиент. Пока это не слишком реалистично, но перспективы есть.
                                                                                                0
                                                                                                полностью согласен) плюсанул бы, но нет такой возможности
                                                                                                  –1
                                                                                                  полностью согласен) плюсанул бы, но нет такой возможности
                                                                                                  0
                                                                                                  упс, что с кодировкой?
                                                                                                  • НЛО прилетело и опубликовало эту надпись здесь
                                                                                                      0
                                                                                                      Я считаю, что не стоит приносить "нативность" стандартизованной технологии в жертву удобству. Хотя технически это, конечно, возможно - и даже видел примеры подобных расширений.
                                                                                                      • НЛО прилетело и опубликовало эту надпись здесь
                                                                                                          0
                                                                                                          С очень большой вероятностью получится очередной, 1001-й XML-подобный (недо)язык, который придется учить кому-то кроме его разработчиков. Я пока не могу придумать таких фич, чтоб настолько упростить процесс разработки, чтоб оно того стоило.
                                                                                                        0
                                                                                                        в данном случае мы ориентируемся на данные, а на шаблон. хотя вполне интересный вариант.
                                                                                                        0
                                                                                                        «В роли средства преобразования XML-документов XSLT не нуждается ни в какой реабилитации. Но к использованию XSLT в качестве шаблонизатора в CMS/CMF это не имеет отношения.»

                                                                                                        Во! Золотые слова.
                                                                                                        А основная проблема с XSLT лежит за его пределами - как раз в упомянутом вами представлении документа в формате XML. А защититься от дурака-программиста, к сожалению, намного сложнее, чем от дурака-верстальщика :)
                                                                                                          0
                                                                                                          >Когда стоит задача преобразования уже предоставленного XML (например, полученного от некоторого удаленного сервиса) - >разумеется, XSLT будет оптимальным вариантом, он для этого и сделан.

                                                                                                          Не всегда, смотря какое преобразование. Попробуйте например с помощью XSLT преобразовать документ с "плоскими" хедерами

                                                                                                          в структурированный а-ля XHTML 2.0 ... . Геморой еще тот...

                                                                                                            0
                                                                                                            ой сорри, забыл что тут тэг h1 нельзя вставлять :)
                                                                                                            0
                                                                                                            спасибо за этот коммент особенное!
                                                                                                              0
                                                                                                              >>Чтоб писать лаконичные, не повторяющиеся, параметризуемые и гибкие шаблоны,
                                                                                                              >>нужно научиться думать в таком стиле. Но, ИМХО, оно того стоит.
                                                                                                              Научите пож-ста думать в другом стиле!
                                                                                                              Я с этой технологией работаю с полгода, и все равно не могу сказать что все "раскурил".
                                                                                                              Примеры в сети помогают слабо, приходится порой сильно париться.
                                                                                                              Действительно надо перестраивать мышление.
                                                                                                              Давно бы кто нибудь завел блог про практический XSLT.
                                                                                                              Ау профи!
                                                                                                                0
                                                                                                                Отличная идея про блог!
                                                                                                                  0
                                                                                                                  Есть уже, только не здесь
                                                                                                                  http://clubs.ya.ru/4611686018427388239/ - здесь порядка 50 профессиональных XSLT разработчиков
                                                                                                                  только они как правило темы о XSLT обсуждают не в блоге, а в курилке...
                                                                                                                  0
                                                                                                                  Полутора недель на освоение XSLT, разумеется, не достаточно. Хотя там всего-то десяток употребительных конструкций. Через полторы недели, как правило, верстальщик начинает писать код "как-на-смарти". Ну или как на PHP. Один шаблон, пачка вложенных for-each, ветвление через choose где ни попадя, дублирование кода и прочие радости. Много раз такое видел.
                                                                                                                  для достижения этого уровня достаточно и трех дней...
                                                                                                                  я видел не один десяток XSLT разработчиков которые достигали этого уровня за 3 дня
                                                                                                                  иногда люди за три дня успевают разобраться в групперовке
                                                                                                                  +1
                                                                                                                  Пользую Smarty, подумываю пересесть на XSLT, но вот преимущества пока выглядять хлипко. По идее микроскопом и гвозди можно забивать, но лучше всё-таки использовать по назначению. Также и со смарти. Правда вот XML... Если её юзать достаточно активно, то смарти канеш будет не к месту. Пока же я по-старинке всё.
                                                                                                                    0
                                                                                                                    Холивар.
                                                                                                                    В каментах почему-то все исходят из противопоставления XSLT - Smarty. В то время как и то и другое - крайности, и оба решения имеют массу недостатков. XSLT жутко сырой без примочек типа EXSLT, кроме того требует определенного стиля мышления, и иногда тривиальные задачи там решаются очень нетривиальным способом. Использовать XSLT сложнее чем просто прописать {$var} внутри html (отсюда и зарплата выше), кроме того он требует начальных данных в XML, то есть этот XML еще нужно составить.
                                                                                                                    А Smarty наборот перегружен ненужными фичами, из-за чего многие соблазняются писать на нем бизнес-логику.
                                                                                                                    Если уж говорить про php, мой выбор - Blitz или native php.
                                                                                                                      0
                                                                                                                      да, {$var} проще. только еще нужно узнать, что этот $var там есть и как он называется. это решается 3мя способами:
                                                                                                                      1. спросить программера
                                                                                                                      2. я сам программер
                                                                                                                      3. посмотреть документацию, которая, разумеется, полная, подробная и мне понятная.

                                                                                                                      4й вариант - не вариант.
                                                                                                                      0
                                                                                                                      А что, МойКруг переписали под XSLT? Там же, вроде, Smarty раньше был.

                                                                                                                      Отладка шаблона на XSLT, если в нем допущена ошибка, может потребовать от разработчика существенных усилий по ее нахождению и устранению…
                                                                                                                      Большинство описанных в этом абзаце проблем решается вменямым девелопером с хорошим инструментом разработки на раз.
                                                                                                                        0
                                                                                                                        МойКруг был куплен Яндексом, вот потому там и XSLT
                                                                                                                        +2
                                                                                                                        отличная статья!

                                                                                                                        При переходе на XSLT со Smarty не доволен им был примерно недели полторы-две...
                                                                                                                        Месяца через два понял, что к Smarty возвращаться нет ни малейшего желания)

                                                                                                                        По поводу производительности. Имел опыт создания тестов возможности внедрения Smarty в CMS написанный с использованием XML+XSLT и при этом суть XSLT была реализована процентов на 80%-90%. Т.е. можно и лучше - но уже почти то что надо))
                                                                                                                        Пришел к выводу, что производительность у XSLT и Smarty практически равна.
                                                                                                                        НО при совершенно различных подходах.
                                                                                                                        Если использовать подход Smarty в XSLT - тормозит (о чем говорилось в статье)
                                                                                                                        Но если использовать наоборот - подход XSLT используя Smarty - тормозит еще больше. :)

                                                                                                                        Кроме того - мне лично гораздо удобнее использовать древовидные структуры - XSLT это работает гораздо быстрее и удобнее.

                                                                                                                        Ну и опять же "стриктовость" мне нравится очень. Не будет никаких незакрытых тэгов и т.п.
                                                                                                                        А грамотно форматированный код читать гораздо удобнее, чем такой же смартёвый.
                                                                                                                          0
                                                                                                                          Так же и продолжайте писать на Хабре.
                                                                                                                          Приятная статья, и, что самое страшное, я разделяю большинство Ваших взглядов.
                                                                                                                            +2
                                                                                                                            merci!
                                                                                                                            Раз уж зарегистрировался - буду писать еще. Есть еще много что сказать.
                                                                                                                            Если противники не заминусят ;)
                                                                                                                              0
                                                                                                                              За объективные аргументы и мнения не минусуют. В основной массе на Хабре адекватные специалисты или к ним приближенные.
                                                                                                                              Так что удачи :)
                                                                                                                            0
                                                                                                                            В своём опыте разработки web - проектов, повидал многое.
                                                                                                                            Начиная от смеси php+html - как в битриксе например :(, заканчивая своими шаблонами и изобретением велосипеда.

                                                                                                                            Но пришёл всётаки к xslt.
                                                                                                                            Скорость работы, говорят некоторые? Честно скажу отличная.
                                                                                                                            Поддержка? Без проблем.
                                                                                                                            Разобраться в чужих шаблонах? Поверьте легче, чем к примеру в смарти.
                                                                                                                            При этом не надо знать php или другие языки, и бояться, что из-за чужого говнакода, вы потрёте глобальную переменную.

                                                                                                                            Минусы таковы. Всё что есть в интернете и в книгах по xslt, очень тяжело перенести в web.
                                                                                                                            Там рассказываются о возможностях, абстрактные примеры, спецификации.
                                                                                                                            А вот с примерами для web проблема.
                                                                                                                            Проблема и с php. Многие хостеры не любят обновляться. А вот php и libxml - если старые, там есть траблы.

                                                                                                                            Короче XSLT вещь. И всем советую. Одна проблема, чтобы научится его использовать и учесть многие нюансы, нужно много терпения и времени :( - Поэтому наверное xslt - верстальщики и стоят дорого.

                                                                                                                            Да совсем забыл. Есть люди увлекающийся типа всё в ООП, всё в функциях, и всё в XML и т.п. Я не фанат такого подхода. И призываю использовать XSLT - там где это нужно.
                                                                                                                              0
                                                                                                                              Небольшой вопросик от новичка в XSLT.

                                                                                                                              А разве сейчас уже три основных браузера не умеют сами, получая связку XML+XSLT, его трансформировать? Потому что я когда я себе тесты делал - именно так и было: был xml с данными и подключенным темплейтом XSLT. XML напрямую отдавался браузерам - а они показывали все так, будто он уже в HTML. То бишь генерация контента отдана клиенту и не тормозит сервер - ибо шаблон статичен, а XML если и динамичен, то уж точно не медленнее, чем если отдавать те же данные в виде HTML.

                                                                                                                              В общем вопрос тупой - если клиент может рендерить XML+XSLT, нафиг какие-то серверные преобразователи?
                                                                                                                                0
                                                                                                                                Тупой ответ:
                                                                                                                                делать трансформацию на клиенте - это преступление :)

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

                                                                                                                                Ничего личного :)
                                                                                                                                  0
                                                                                                                                  для таких как ты придумали поле User-Agent: MegaOldAndSlowBrowser
                                                                                                                                  0
                                                                                                                                  Делюсь опытом тезисно :)
                                                                                                                                  1. Браузеры умеют рендерить XSLT, по-разному
                                                                                                                                  2. Не все версии браузеров это умеют (к примеру, opera)
                                                                                                                                  3. В мобильных версиях браузеров тоже проблемы
                                                                                                                                  4. До сих пор не знаю, как будет индексироваться такой сайт. (в яндекс, внятно не ответили. больше не писал. может, и умеет)
                                                                                                                                  5. Если xsl'ка не догрузится, мы вообще ничего не увидим

                                                                                                                                  Из плюсов - удобно в ajax'е. Небольшие шаблоны можно использовать и для серверной обработки и грузить на клиенте. Бывает удобно и вообще повторное использование кода это добро.
                                                                                                                                    0
                                                                                                                                    Тут есть ряд проблем.

                                                                                                                                    1. Индексация поисковиками, как уже было сказано. Возможно, они и сожрут XML, но есть еще один тонкий момент - фактически, получается, что робот и пользователь видят разные данные, а это называется словом "клоакинг", и поисковики такое не любят.

                                                                                                                                    2. Поддержка браузерами. Opera до 9 версии вообще никак не поддерживала. Firefox, например, игнорирует disable-output-escaping, соответственно нет возможности отдавать куски HTML-кода как CDATA.

                                                                                                                                    3. XSLT-шаблон вовсе не обязан быть статичным. В больших проектах с множеством модулей вес шаблона может оказаться весьма большим, поэтому иногда приходится собирать шаблон по частям.
                                                                                                                                      0
                                                                                                                                      Tvarb, lyxsus, dubr - спасибо большое за культпросвет!
                                                                                                                                      Буду знать наперед о проблемах.
                                                                                                                                    0
                                                                                                                                    Вот, кстати, только что наткнулся:
                                                                                                                                    Протоколы UData, UPage, UObject, UFS
                                                                                                                                    Данные протоколы используются xslt-шаблоном для получения данных из БД
                                                                                                                                    на сервере.


                                                                                                                                    Это из мануала по использованию XSLT в UMI.CMS.

                                                                                                                                    Мне кажется, это отличный пример порочной практики. Когда, вместо использования стандартных средств, разработчики придумывают что-то космическое. Заставляя вникать в то, как устроена их система изнутря, и при том нарушая стройность архитектуры. Ну блин, не должен шаблон решать, показывать ли меню на странице. Шаблон должен содержать средства для отображения меню, если приложение решило, что нужно его отобразить. Я с UMI плотно не работал, может это и удобно в некоторых случаях. Но идеологически выглядит не правильно.

                                                                                                                                    Чего XSLT действительно не хватает - так это функций форматирования даты / времени, и, местами, регулярок. И то, и другое реализовано в exslt, и, кажется, заложено в стандарт 2.0.

                                                                                                                                    А нагружать шаблоны средствами для работы с бизнес-логикой, как это делают UMI (например, в шаблон передаются GET-параметры - ну нафига они там?) - ИМХО, не нужно.
                                                                                                                                      0
                                                                                                                                      >>Ну блин, не должен шаблон решать, показывать ли меню на странице. Шаблон должен содержать средства для отображения меню, если приложение решило, что нужно его отобразить.

                                                                                                                                      Может быть я что не понимаю, или мы говорим о разных "шаблонах"?

                                                                                                                                      Шаблон ничего не должен решать :)
                                                                                                                                      Я ему говорю выведи мне здесь меню - и он выводит :)

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

                                                                                                                                        Я как раз и говорю, что шаблон ничего решать не должен, он должен отображать то, что собрала для него система. Т.е. нужно ли собрать меню или какой-либо другой блок - решает система. Максимум, что может шаблон - отображать или не отображать определенный блок. Т.е. в шаблоне можно написать xsl:apply-templates select="someblock", а можно и не писать :) А в документации от UMI описан пример, когда меню не будет собрано, если не попросить об этом в шаблоне при помощи xsl:apply-templates select="document('udata://content/menu')//item". Не знаю, как именно механически устроен протокол udata, но по сути, при помощи него шаблон указывает приложению, что оно должно делать.

                                                                                                                                        Кстати, я подозреваю, что пользователь посмотреть профиль lyxsus, участвующий в данной дискуссии, имеет отношение к обсуждаемой системе (судя по тому, что ник упомянут в одном из примеров документации). Возможно, он даст нам свой комментарий :)
                                                                                                                                          0
                                                                                                                                          Так давайте расставим точки над "i" и отойдем от UMI.CMS

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

                                                                                                                                          <xsl:apply-templates select="document('udata://content/menu')//item" />


                                                                                                                                          Результатом данного запроса будет выданное с учетом прав пользователя xml дерево сайта.

                                                                                                                                          >>при помощи него шаблон указывает приложению, что оно должно делать.
                                                                                                                                          не указывает - а просит систему дать меню если оно есть и пользователя есть на это право :)

                                                                                                                                          А если мне по дизайну не нужно меню?
                                                                                                                                          Зачем мне автоматический лишний запрос в базу?

                                                                                                                                          Если меню нужно по дизайну - оно запрашивается, если нет - то нет:)

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

                                                                                                                                          Если идти по Вашему варианту, где система решает по какому-то там "default" какие данные мне нужны, то большая вероятность их избыточности - мне придется отсекать лишенее.
                                                                                                                                            0
                                                                                                                                            Да, избыточность действительно порой возникает. Видимо, лично для меня важнее стройность системы.

                                                                                                                                            В моем представлении формированием модульной сетки должен заниматься контроллер. Однако, все знают, что в веб-приложениях очень часто по вполне объективным причинам границы ответственности в рамках MVC весьма призрачны. Так что в данном случае нужно разбираться в архитектуре UMI, с которой, повторюсь, я не слишком хорошо знаком.

                                                                                                                                            Больше всего меня смущает, что шаблон должен обладать информацией о внутреннем устройстве приложения. С другой стороны, если интерфейс запросов в достаточной степени абстрактный, ясный и лаконичный - может это и не страшно. Но только по документации об этом сложно судить, надо смотреть на практике.
                                                                                                                                              0
                                                                                                                                              Раз уж заглянул в эту тему — вот мои мысли почти год спустя :)

                                                                                                                                              Много думал над этим вопросом. Пришел к выводу, что сборка модульной сетки — вообще отдельный уровень логики. По очевидным обстоятельствам за этот уровень часто отвечает тот же механизм, что и за шаблонизацию. Получается активный шаблон. Т.е. это 2 разных шаблона: один выводит обвязку (и он может решать, что где подгрузить), второй — всю конкретику. Эти сущности сильно отличаются и логически, и практически (например, видел систему, где модульная сетка формируется мешаниной PHP+HTML, а сами модули шаблонизируются через XSLT).

                                                                                                                                              Я в своих исканиях пошел по другому пути, у меня за сборку модульной сетки отвечает хитрая независимая система правил. Умные люди мне сказали, что это Front Controller :)
                                                                                                                                              Слабое место: эта система должна знать кое-что о дизайне — что у нас есть шапка, левая колонка, правая колонка и т.д., и что при некоторых обстоятельствах обвязка может меняться.
                                                                                                                                              Сильная сторона: эта система может знать гораздо больше о контексте приложения, чем положено знать привычному шаблону. Кроме того, эта система может содержать куски, написанные в императивном стиле (ага, спагетти из if-else), хотя в большинстве случаев хватает декларативных правил. Писать же такую логику на декларативном языке — кощунство и извращение.

                                                                                                                                              Ваш пример с меню — все-таки плохой. Не может быть отображение меню вопросом дизайна. Не может дизайнер сказать: «не буду рисовать меню на этой страничке, оно тут плохо смотрится». Дизайн вторичен, дизайн оформляет то, что по логике приложения должно быть отображено. А логика может быть весьма сложной. В итоге приверженцы «активного шаблона» вынуждены плодить шаблоны под каждый тип страницы, что чревато известными неприятностями.
                                                                                                                                              +1
                                                                                                                                              так точно. я занимаюсь непосредственно проектированием системы.
                                                                                                                                              сейчас объясню, почему работает именно так.

                                                                                                                                              1. По поводу xslt, xml в принципе.
                                                                                                                                              У нас прижился принцип: давать ровно столько данных, сколько необходимо не больше и не меньше. Это продиктовано все той же необходимостью уменьшить размер XML-документа, который необходимо генерить. + еще это достаточно элегантно.

                                                                                                                                              2. Принцип, на котором построены внутренние url-схемы.
                                                                                                                                              Этот подход обусловлен желанием соответствовать идеологии REST.
                                                                                                                                              С этой точки зрения CMS предоставляет набор сервисов. Совсем не важно, как они сгенерировались. Возможно, из кеша, возможно, еще откуда-то. Это неважно. Важно то, что они там есть, что они нужного формата.
                                                                                                                                              И системе тоже неинетерсно, откуда эти сервисы вызываются: через XSLT, из FLASH-версии сайта, через AJAX, через десктопное приложение, и т.д..
                                                                                                                                              Это тот же вариант, что и mash-up. При желании я всегда могу, например объединить список новостей со своего сайта со списком новостей с сайта-сателита. Или брать их из интранет-системы.

                                                                                                                                              Такой подход дает и такое преимущества как:
                                                                                                                                              1. Независимость тестирование. можно тестировать не всю систему, а отдельный сервис. и это наглядно.
                                                                                                                                              2. Если какой-то сервис "отваливается": внутренний или внешний, то это не смертельно.
                                                                                                                                              3. Всякие гаджеты и плагины собираются практически мгновенно. К примеру малополезный, но показательный плагин к firefox'у: http://www.umi-cms.ru/extensions/umi_lic… собран меньше чем за пол часа в процессе изучения плагинов firefox'а.
                                                                                                                                              4. Это поддержка AJAX'а и, наример, флеш-сайтов без лишних движений.

                                                                                                                                              И все эти сервисы учитывают права доступа, и прочее, что у нас делается на бэк-энде.

                                                                                                                                              PS1. Хочу отметить, что внутренние схемы придумали не мы, а подсмотрели у достаточно крутого XSLT-фреймворка.
                                                                                                                                              PS2. Хорошим примером в пользу REST для нас явился google. Не помню, чтобы он когда-либо сильно ошибался в технологическом плане.
                                                                                                                                                0
                                                                                                                                                Спасибо за ответ :)

                                                                                                                                                Постараюсь найти время и разобраться, как оно у вас все устроено. Пока, боюсь, мне нечем возразить аргументированно.

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

                                                                                                                                            Теперь насчет параметров. Я тоже размышлял об их необходимости, и тут достаточно неоднозначно. Зачастую это не нужно.
                                                                                                                                            Если кратко, то параметры могут управлять отображением. Больше особо с ними ничего не сделаешь. Судя по наличию в xslt инструкции "xsl:param", с помощью которой в т.ч. можно передавать параметры в шаблон, так считали и разработчики стандарта. А передать в качестве параметров что-то из get'а вполне разумно. В конце концов шаблон имеет право это знать.
                                                                                                                                            Если бы в xslt можно было использовать переменные (не константы), такую возможность давать было бы действительно небезопасно. :)
                                                                                                                                              +1
                                                                                                                                              Ну дату время можно собственно на уровне обычного кода
                                                                                                                                              отформатировать перед трансформацией… хотя вполне согласен что данной фичи не хватает

                                                                                                                                              Дата парсинг:

                                                                                                                                              geekswithblogs.net/workdog/archive/2007/02/08/105858.aspx
                                                                                                                                              articles.techrepublic.com.com/5100-22_11-5075671.html#CodeExample53

                                                                                                                                              Регулярки в XSLT 2 как вижу есть, хотя ни разу не приходилось пользовать…
                                                                                                                                              www.xml.com/pub/a/2003/06/04/tr.html

                                                                                                                                                0
                                                                                                                                                Да, я собственно так и делаю — в шаблон отправляется уже оформленная дата. Хотя это неправильно. То, что предлагают по ссылкам — не сильно лучше. Я еще одно время пытался отдавать дату в шаблон в каком-то таком виде:

                                                                                                                                                <date day="01" month="09" year="2009" month-name="Сентябрь" month-gen="Сентября" />

                                                                                                                                                руководствуясь мыслью, что писать «1 сентября 2009 года» или «01.09.09» — все-таки вопрос дизайна. Но быстро надоело, уж больно громоздко. Есть еще вариант с php:function(), но он не труЪ, ибо проприетарен (exslt тужа же).

                                                                                                                                                Регулярки в XSLT2 радуют (точнее, вообще арсенал работы со строками в новом xpath), не радует туманность перспектив самого XSLT2 для нас — рядовых пыхеров :)
                                                                                                                                              0
                                                                                                                                              По-моему, в проектах, где используются простые шаблоны, а if/else - это максимально сложная, доступная верстальщику, конструкция, такой сильный инструмент не очень нужен. Вернее, сотруднику нужно обосновать изучение хорошего фолианта по XSLT, которое даст ему только увеличение времени на разработку и поддержку (и, как следствие, рост трудозатрат в целом, на поддержку особенно).

                                                                                                                                              С другой стороны, если речь идет о крупном проекте, над которым работают хорошие профессионалы с золотыми руками - такой подход будет только бонусным.
                                                                                                                                                –1
                                                                                                                                                xml вообще сложно воспринимается человеком. а шаблоны xslt часто бывают просто нечитаемыми.
                                                                                                                                                стандарт - может быть. удобство - сомнительно.
                                                                                                                                                  0
                                                                                                                                                  Вы неправы.
                                                                                                                                                  Я уже в течении часа смотрю всевозможные туторы и примеры.
                                                                                                                                                  И знаете… Все предельно и интуитивно понятно.
                                                                                                                                                    0
                                                                                                                                                    всё познается в сравнении. посмотрите, например, yaml
                                                                                                                                                  0
                                                                                                                                                  XSLT и Smarty это совсем разные вещи.
                                                                                                                                                  Smarty написан на том же php. XSLT отдельная технология. Работает на разных платфорамах и на уровне, выше чем Smarty. Не пойму откуда спор по поводу производительности.
                                                                                                                                                    +1
                                                                                                                                                    Еще пару слов в пользу XSLT. Долгое время работал с системой, использующей для отображения XSLT. Не стоит бояться о скорости ее работы. Все работало с хорошим быстродействием – а это была сотни 2 магазинов на одной обычной машинке (P4, 1Gb, IDE), по посещаемости весьма приблизительно – по 200 хостов на сайт в день.

                                                                                                                                                    Все зависит от того как построить систему. Если генерировать каждую страницу на запрос, к тому же каждый раз для этого строить немаленькую XML – то естественно будут проблемы с производительностью.

                                                                                                                                                    Но если хорошо построен механизм кэширования. Как на уже сформированный HTML, к примеру, так еще и кэшировать XML для отдельных объектов, с которых потом быстро можно собрать XML для страницы. Нагрузка на подсистему генерации страниц будет небольшая.

                                                                                                                                                    При этом получаем удобство XSLT. Например, подумайте как бы вы реализовали вывод названия товаров на странице, отсортированных по алфавиту, из списка товаров на странице. В XSLT – пара строчек, а на том же Smarty без дописывания кода на PHP уже не обойдетесь.
                                                                                                                                                    И еще один момент – вы можете позволить менять шаблоны кому угодно, и он не сможет что-либо испортить в системе, получить доступ к коду той же CMS (что удобно, если вы не хотите открывать ее код).
                                                                                                                                                    • НЛО прилетело и опубликовало эту надпись здесь
                                                                                                                                                        0
                                                                                                                                                        Имхо, XSLT - отличная вещь, но чтоб внедрять ее в реальные проекты для реальных заказчиков за реальные $$$ надо 3-4 проекта сделать некоммерчиских, чисто для изучения технологии. А это зачастую слишком долго.

                                                                                                                                                        При упоминании XSLT у меня в горле встает комок примерно того же размера, что при упоминании о регулярках. И то и то хорошо, но ты в этом либо спец с опытом, либо ничего.
                                                                                                                                                          0
                                                                                                                                                          Имхо, быть пластическим хирургом - отличная вещь, но чтобы получать за одну операцию по несколько тыщ $$$ надо лет 7-10 учиться и практиковаться ;)


                                                                                                                                                          Вам не кажется, что дело не в XSLT, а просто мир так устроен? ;)
                                                                                                                                                            0
                                                                                                                                                            Да, именно так мир и устроен. Но ваша аналогия немного не в ту степь :-) Много пластических хирургов никому нафиг не надо ), а здесь людей манят на то чтоб все тратили драгоценное время для улучшения своего дзена. И это хорошо, вопрос лишь если я выучу XML/XSLT и начну внедрять в проекты, как мне заставить учить его других сотрудников и кто за это платит?
                                                                                                                                                              0
                                                                                                                                                              не волнуйтесь, много спецов на IT рынке в ближайшие несколько десятилетий не будет точно.
                                                                                                                                                              вообще, много спецов нигде не бывает.

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

                                                                                                                                                              насчет "кто платит" - если изучите рынок вакансий, увидите, что платежеспособный спрос на кодеров с xslt велик и платят на 30-50% больше.
                                                                                                                                                                0
                                                                                                                                                                Ну что ж, поживем - увидим. Пока что я хочу изучить питон и его платежеспособный рынок (количество, на самом деле, пофиг, главное чтоб не ниже планки) по сравнению с пхп, так как последний надоел. Думаю через пол годика уже полностью на питон пересесть.

                                                                                                                                                                А XML/XSLT когда-то применял, сейчас не скажу что проекты со smarty и простых шаблонизаторах при правильной проектировке плохи. Никакого вмешательства в бизнес-логику и так далее нету.

                                                                                                                                                                Единственное что действительно сейчас пригодилось бы - клиент-обработка шаблона. Вот это рулит на высоконагрузочном проекте где шаблонизатор пыхтит.
                                                                                                                                                                  0
                                                                                                                                                                  Библиотека libxslt, которую удобно в Python использовать, гораздо лучше чем трансформер в PHP, который работает с ошибками, и в котором функции расширения реализованы через одно место.
                                                                                                                                                                    0
                                                                                                                                                                    Синтаксис XSLT это не меняет :-)
                                                                                                                                                                      0
                                                                                                                                                                      В PHP меняет, т.к. некоторые вещи не работают, это касается в большей мере XPath. Именно поэтому мой выбор пал на питон, а то выбрал бы PHP, т.к. он более распространен.
                                                                                                                                                                        0
                                                                                                                                                                        А что за некоторые вещи, если не секрет?
                                                                                                                                                                          0
                                                                                                                                                                          Я уже не помню детали, коллеги, программирующие на PHP, постоянно меняют решение задачи, т.к. некоторые XPath просто не работают, специально проверяли на других трансформерах, решения были рабочими. Еще хороший трансформер, полностью поддерживающий стандарт, в .Net, хотя самый быстрый (и на сегодняшний день даже вроде) это msxsl.
                                                                                                                                                                            0
                                                                                                                                                                            В общем, если будут детали - с радостью посмотрю и потестирую проблемы с XSLT в PHP. У меня какие-то тоже были, но их решили быстро помню.

                                                                                                                                                                            Про msxsl не слыхал, но сдается мне, это что-то с MS связано, и скорее всего для меня оно не существует под линухами.
                                                                                                                                                                              0
                                                                                                                                                                              В понедельник попробую детали выяснить, наверняка их описали чтобы не повторять "ошибки", здесь отпишусь. Да msxsl (из msxml4) это детище мелкомягких, хороший продукт, я с него начинал знакомство с XSLT :)
                                                                                                                                                                              0
                                                                                                                                                                              в php использовал xml& xslt. были некоторые проблемы ( не работала функция index-of(),empty(),..) с xpath. но пенять особо не на кого, т.к. dom в php хоть и относительно давно, но все равно не полностью поддерживается и не очень стабилен. хорошо, что хоть наиболее распространённые функции реализованы.

                                                                                                                                                                              решал проблему альтернативными xpath запросами. иногда полученное решение теряло изящность технологии,имхо.
                                                                                                                                                                        +1
                                                                                                                                                                        а что в PHP нельзя libxslt использовать? я первый раз слышу про трансформер в PHP, который работает с ошибками... я всегда думал что кроме libxslt в php ничего другого и не используют

                                                                                                                                                                        советую посмотреть сюда

                                                                                                                                                                          0
                                                                                                                                                                          Когда-то был Sablotron, и он правда был ужасен :) Видимо, о нем и вспомнили.
                                                                                                                                                                            0
                                                                                                                                                                            Наверное, я уже давно не интересовался как у PHP дела с XSLT.
                                                                                                                                                                            Надо будет еще раз посмотреть что там сейчас.
                                                                                                                                                              0
                                                                                                                                                              При разработке проектов для клиентов компании и для самой компании мы в свое время столкнулись с тем, что использовать "шаблоны" APS.NET опасно для психики и для проектов.
                                                                                                                                                              Идею использовать XML+XSLT в качестве движка шаблонов подсказал небольшой проектик, надо было прилепить еще старое Google Search API, которое было в виде SOAP Web Service.
                                                                                                                                                              Получить XML от веб-сервиса, сделать трансформацию и на выходе получить красивую страниу с результатами поиска.
                                                                                                                                                              Разобравшись с технологией, оказалось, что MS SQL замечательно возвращает результаты запросов в виде XML, C# получает XML, делает трансформацию. В итоге весь код занимает пару строчек. Для AJAXa можно использовать трансформацию на клиенской стороне. Встроеный набор функий XSLT можно раширять за счет написания функций на C# - ms-xslt это поддерживает.
                                                                                                                                                              Все очень красиво, элегантно, читабельно.
                                                                                                                                                              Автору спасибо за тему - я думала мы одиноки в использовании этой технологии.
                                                                                                                                                                +1
                                                                                                                                                                когда я над сайтами МТС работал, то там всё висело под парсером и на XSL шаблонах.
                                                                                                                                                                не люблю XSLT, но должен признать - лучшего шаблонизатора я ещё не встречал в просторах всемирной...
                                                                                                                                                                  0
                                                                                                                                                                  Непонятно как вообще битрукс может наезжать по xml/xslt, их тварение чудовищно, оно убыточно и место ему на серверах типа Народ.ру. Если бы не туролобость и глупость менеджеров то битрукс никода бы не стал "лидером".

                                                                                                                                                                  Что касаемо XML/XSLT то здесь не может быть проблем, надо признать что для применения его в промышленных маштабах нужно в цепочку програмист верстальщик вклинить еще одного человека js xml xslt програмиста, тогда дело пойдет совсем по другому, обычный пхп програмист не всегда способен воспринять логику xml есму проще поставить 20 проверок чем думать об базе глобально так же как и верстальщик недостаточно развит как правило до xml.

                                                                                                                                                                  php активно работает над парсером и с каждым выпуском дело идет к лучшему.
                                                                                                                                                                    0
                                                                                                                                                                    Браво. То, что я понимал лишь инстинктивно вы виртуозно разложили по полочкам. Я хочу быть вашим другом. :)
                                                                                                                                                                    На счет сложности отладки с вами я только не соглашусь. Любой xslt-процессор (xsltproc) махом выдаст вам в каком месте ошибка.
                                                                                                                                                                      0
                                                                                                                                                                      Насчет того, что XML стандарт и очень хорошо - полностью согласен. Но объясните мне, дурню, зачем вынимать данные из базы в чистом виде, потом преобразовывать их в валидный XML и тут же!!! скармливать XSLT шаблонизатору? Давайте, тогда, до кучи, их еще в какой-нить формат преобразуем. Считаю, что пока в MySQL не появится нормального решения, позволяющего получать данные сразу в XML все эти разговоры об XML и шаблонизаторах не прекратятся.
                                                                                                                                                                        0
                                                                                                                                                                        Что значит "в чистом виде"? Это что за формат данных такой? В большинстве трансформеров XSLT можно использовать функции расширения, вот и передавайте в эту функцию SQL-запрос, и получайте на выходе XML, который тут же можно обработать средствами XSLT.

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

                                                                                                                                                                          Поймите, я в состоянии и сам написать преобразователь SQL query -> XML или просто преобразователь результатов, полученных из базы, в XML. Речь то шла не об этом, а о том, что получается лишняя, и довольно тяжеловесная трансформация. Может что-то и появилось за последнее время, но я быстро работающего решения для PHP пока не видел.
                                                                                                                                                                            0
                                                                                                                                                                            Я не придираюсь, просто для любого шаблонизатора данные придется в какой-либо формат преобразовывать. Я пользовался следующими трансформерами: msxsl3, msxsl4 (или msxml3/4???), трансформер из .net 1.1, и libxslt из питона. Все они работают довольно быстро, разве что .net-овский кушает много памяти при большом XSLT, необходима оптимизация.

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

                                                                                                                                                                            Я в данный момент для формирования XML из базы использую libxml2 - данные сразу формируются в DOM, и потом "натравливаю" на них XSLT-трансформацию. SQL-запросы более медленная операция из всех других, так что оптимизацию по скорости надо делать в другом месте.
                                                                                                                                                                        0
                                                                                                                                                                        Никто не привел никаких примеров.

                                                                                                                                                                        Вот пример бесплатного форума который работает на XSL, причем поддерживает и сервернюу и клиентскии трансформацию:

                                                                                                                                                                        http://www.demozzz.com/orca/demo/?xsl_mode=server
                                                                                                                                                                        http://www.demozzz.com/orca/demo/?xsl_mode=client
                                                                                                                                                                          0
                                                                                                                                                                          Мне лень всё читать, но вы не правы.
                                                                                                                                                                          Любой xsl-процессор упадёт, если вы подсунете ему невалидный xsl-шаблон.
                                                                                                                                                                          Наличие оператора if/switch(в том или ином его виде) XSLT как раз таки позволяет смешать бизнес-логику и логику представления так же легко, как и в smarty.
                                                                                                                                                                          "Все технологические преимущества XSLT основаны на основной концепции, заложенной в него, - полное разделение бизнес-логики и логики представления" - бред, о чём вы говорите ?? XSLT - вам расшифровать абревиатуру ? Он создавался для преобразования xml-документа одного формата в другой.

                                                                                                                                                                          Если вы хотите продвигать свои бизнес-проекты, то вешайте баннеры, а не пишите такие "статьи" с целью повлиять "на умы некоторых непосвященных разработчиков" ! Не на том сайте написали !
                                                                                                                                                                            +1
                                                                                                                                                                            В данный момент как раз работаю над созданием доски объявлений, там очень много повторяющихся щаблонов с небольшими отличиями, попробовал применить XML/XSLT, очень понравилось! Производительность на уровне, а если кэшировать грамотно, то вообще супер, количество кода сократилось раз в 7, 8! Единственный "минус" пришлось потратить время на изучение X-технологий!
                                                                                                                                                                              0
                                                                                                                                                                              Хочется верить, что XSLT станет популярнее с появлением специального вычислительного облака под него. Там была бы поддержана лишь одна СУБД хранящая все данные в массиве xml-файлов, ну и язык поддерживался бы только один — XSLT.

                                                                                                                                                                              Язык хорош тем, что прост при всей мощности в реализации бизнес-логики, но его хочется обрамить более комфортной СУБД (коммент выше про это), ну и облачным удобством, что бы было как в Heroku или в нашем dokkur.com.

                                                                                                                                                                              Стараюсь реализовать это в рамках проекта «формуляр» (https://github.com/m8data/formulyar).

                                                                                                                                                                              Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

                                                                                                                                                                              Самое читаемое