Материалы /

20.03.2008 15:45

Сергей Котырев, глава компании Юмисофт, опубликовал на Хабре статью в защиту 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, тем больше денег заработают в будущем.