— Как-то у вас ровно всё. Продумано и разложено по полочкам, -
пожаловался Иван Иваныч Петру Петровичу.
— А как ты хотел, барин? XSLT, между прочим, промышленный стандарт разработки сайтов! - недоумённо переспросил Пётр Петрович.
— Да я как-то проще привык, - скривился Иван Иваныч, - чтоб фигню всякую быстро написал, сдал заказчику и забыл.
Последние несколько лет я наблюдаю тотальное падение квалификации веб-разработчиков в Рунете. Является ли это следствием кризиса или рынок веб-сайтов самостоятельно пришёл к резкому удешевлению заказов, неизвестно, но так или иначе у среднего веб-программиста уровень «глубокого понимания» того что он собственно делает фатально стремится к нулю.
Мы испытываем это и на себе тоже. Я регулярно мониторю рынок вакансий и вижу, как компании вынуждены значительно завышать планку оклада, чтобы привлекать специалистов в свои команды. Например, подавляющее большинство кандидатов которые приходят к нам ежедневно, не могут увидеть проблему в php-коде if ... else { echo("Ошибка"); } — хотя проблем тут как минимум две, а кто увидит три — тому я с удовольствием пожму руку.
Массовое явление деградации — налицо. Не думать — это очень соблазнительно и приятно. Чертовски приятно написать линейный код прямо в шаблоне вперемешку с HTML. Тем более что 99% заказчиков провоцируют скорость разработки в ущерб качеству. И на этом строится бизнес. Люди с кривыми руками, соревнуясь друг с другом, пишут и переписывают говнокод веб-проектов, высасывая деньги из карманов заказчиков и создавая им проблемы в будущем.
Чтобы не быть обвинённым в некорректности, скажу: да, иногда имеет смысл написать короткий скрипт линейным кодом. Да, иногда имеет смысл сделать прямой SQL-запрос к БД, а не выдумывать класс-генератор для этой цели. В любом хайлоад-проекте так и делают сплошь и рядом, потому что под миллионами хитов всё остальное прогнётся. Но то хайлоад, а их в Рунете можно пересчитать по пальцам.
В отличие от CMS, основанных на использовании спагетти-кодинга, Юмисофт выбрал академический путь, сделав ставку на современные и рациональные XSLT, ORM и REST.
Некоторым новичкам лень или просто трудно изучать технологию, которая кажется «умнее» тебя. Тем более трудно изучать технологию, которую с первого взгляда не очевидно где ещё можно применить кроме UMI. Да и толщина официальных учебников по XSLT (под 700 страниц) отпугивает.
Но начав знакомство с XSLT с наших демонстрационных сайтов, вы скоро увидите, что чтобы уверенно делать сайты на UMI+XSLT — достаточно 15 минут поразбираться с готовым шаблоном. И получите офигенный профит плюс 100 очков к личной квалификации на будущее. И никаких заумных книжек.
Те, кто пишут «говнокод» — в том числе линейный код вперемешку с шаблонами, — сами роют себе яму. На всём рынке снижаются цены и падает качество разработки, доходы разработчиков падают. А избалованные «быстрыми костылями» заказчики будут меньше платить и больше топать ногами, когда на каждую модификацию проекта потребуется по ходу дела исправлять пятнадцать багов.
И когда вы, начинающие программисты, подрастёте в профессиональном плане и потянетесь к высоким зарплатам, с каждым днём вам всё сложнее и сложнее будет найти работу без «говнокода».
А большие деньги будут там, где требуется масштабируемость и расширяемость системы, переносимость и слабосвязанность компонентов, лёгкость поддержания и внедрения новой функциональности.
Комментирование доступно только авторизованным пользователям.
Пожалуйста, зарегистрируйтесь или войдите на сайт.
Видали мы такие XSLT-шаблоны, что волосы дыбом встают... :)
Но в целом, конечно, Григорий, вы правы - XSLT лучше чем не-XSLT.
К чему я все это пишу?! Меня поражает такое явно пренебрежительное отношение к начинающим программистам и многочисленным вашим партнерам в их лице. Лично Вы, как профессионал, наверно имеете право высказывать подобную точку зрения с друзьями за бутылочкой пивка, а вот как официальное лицо компании - думаю это некорректно.
И вот один вопрос меня все мучает, когда читаю здесь блоги. А что в юми действительно так часто пишут пхп в щаблонах?
В этом посте я озвучиваю именно официальную позицию компании как топ-менеджер - для личных мыслей у меня есть личный блог. А позиция компании такова, что "говнокодеры" убивают рынок, оставляя в перспективе без достойного заработка и себя, и партнёров.
Мы же, со своей стороны, активно поддерживаем начинающих программистов в изучении правильных технологий - по которым к ним потом пойдут деньги. Вот скоро очередные курсы проведём, кстати.
"говнокодеры" портят рынок - да, трудно с этим не согласиться, с другой стороны Вы бы действительно побольше внимания уделяли начинающим программистам, работающим с вашей системой, а не считали их заработки.
Буквально неделю назад, убеждая купить лицензию пришлось просто ломать мнение клиента, которому до нашего знакомства сделали сайт на "Старте". Пришлось объяснять что в юми как и во всех остальных цмс конечно есть недостатки, но не до такой же степени...
Вот такие "гореразработчики" портят ваши репутацию, так работайте с ними, обучайте, помогайте, сертифицируйте, что угодно... а не выставляйте идиотами.
С позиции заказчика, все равно какие технологии применил разработчик, чтобы добиться конечных результатов, если только это не отражено в цене. Поэтому те заказчики которые хотят действительно всесторонне качественный результат, должны выстраивать отношения с подрядчиком исходя из долгосрочной перспективы.
Другое дело разработчики.
Одна из ценностей UMI, для разработчика,это небольшой порог знаний для того чтобы попробовать себя в создании сайтов. И это здорово, что ее можно начать использовать имея маленький багаж технических знаний. В то же время, система не ограничена и имеет действительно академическую архитектуру, что позволяет специалисту развиваться. Думаю, ни кому не хочется оставаться узким специалистом. Так пожалуйста, уже сегодня, UMI.CMS это даже больше чем система для управления сайтом. По сути, это платформа на которой можно быстро разворачивать веб проекты разной специфики. И все то тебе есть, и возможность использовать современные технологии для разработки, и обновляемая документация, и выбор площадки для размещения проекта и обратная связь от самого разработчика.
XSLT это действительно следующая ступенька в изучении UMI после tpl.
И те, кто хочет себя совершенствовать, имеет такую возможность. Ты изучаешь новые технологии, имеешь возможность
применять их на практике, расширяешь список того что ты можешь реализовать и как следствие становишься более дорогим на рынке.
Совершенствуйтесь, инвестиции в себя самого это самое рентабельное предприятие!
Посыл данного блога, совершенно справедливый , команде UMI.CMS спасибо за качественный продукт.
Понимаю что утрированно, но все же.
Я искренний сторонник xslt, как нового и более профессионального решения. Но ведь вопрос как раз в том, что до этой планки надо еще допрыгнуть. Система umi удобна для использования и построена по принципу простоты. А в вопросе разработки принцип другой, либо ты крут и все освоишь, либо... остается только делать сайты практически на основе демо вариантов (при этом боясь сделать шаг влево, шаг вправо).
Весь тот прекрасный потенциал системы... его же не видно, он похоронен за множество мелких моментов, которые не являются сложными по отдельности, но вместе становятся тем самым фактором, из-за которого многим проще написать линейный код, чем писать специальные методы и функции. И вопрос здесь не только в том, что xslt сложен. Сложна совокупность xslt + umi? да даже не в этом, а просто в тонкостях umi. Попробуйте разобраться в вопросе "почему я не вижу нужного шаблона?", "где мне его искать?". Когда я общаюсь с начинающими разработчиками, и они интересуются, где же все-таки найти то или иное и как это работает в umi? Мне приходиться им объяснять, что все просто, но есть вот тут галочка, и есть вот тут кнопка и не забудьте про кодировку. На меня смотрят округлившимися глазами и спрашивают: "А откуда мы должны были это знать". И мне нечего им ответить кроме... ну вот если бы вы прочитали весь help и уложили его в голове, то вы бы поняли... или как это делаю я... залезли в код и поняли, что конкретно хотел сделать разработчик и как это вообще работает.
Не спорю? за последнее время ситуация все лучше и лучше, но я так же продолжаю советовать начинать работать с tpl. В виду того, что сверстанный сайт на xslt это далеко еще не сделанный сайт на umi.
===========================
+5
сторого говоря, разработчики cms и не обязаны учить своих клиентов программированию. Логическое мышление + исходный код + метод научного тыка - в помощь. И хелп надо читать и укладывать в голове, документация пишется не просто так. Уж извиняюсь за якание, но по моей прежней сфере работы - если тебе приносят ТЗ в котором, к примеру, написано, что "уровень радиопомех, создаваемых ...., не должен превышать ..., установленных ГОСТ такой-то для оборудования класса такого-то", то никто не будет разжевывать что это значит, а надо оторвать задницу от стула, пойти в научно-техническую библиотеку, прочитать этот ГОСТ, прочитать ГОСТы, на которые идут ссылки из него, выбрать из этой массы требований те, которые соответствуют конкретно твоему изделию.. Ну а как еще, кто еще будет это делать? Вопросы, да, возникают, но есть большая разница в постановке вопросов, когда он конкретный, т.е. человек что-то делал, искал и понимает о чем говорит, или когда такой, что только посоветовать на компьютерные курсы. На вопросы первого типа СЗ всегда отвечает по существу.
Можно сказать, что документация не полна? да. но мы же все люди, и недочеты неизбежны. ЮМИ логически очень красивая система, надо только помнить, что если чего-то нет в документации, то надо посмотреть исходный код, возможно, просто забыли внести, а если что-то работает не так - тоже посмотреть, возможно, ошиблись. Если сообщить об этом в СЗ - добавят в документацию.
Во всяком случае, у меня никогда не возникало серьезных претензий к ЮМИ по поводу непонятностей.
Именно это (разбирайтесь сами в нашей чудесно программе) приводит к тому, что людям проще работать с менее красивыми системами, но зато более разжеванными.
"то никто не будет разжевывать что это значит, а надо оторвать задницу от стула, пойти в научно-техническую библиотеку, прочитать этот ГОСТ"
вообще для этого надо иметь базис, чтобы найдя ГОСТ понимать, что в нем написано. И этот базис в основном получают как специальность. Я не думаю, что целесообразно создавать специальность "UMI специалист". Но как-то базис-то надо донести до людей, а то UMI получается какой-то вариацией "светлой стороны", а мы как джедаи ("Логическое мышление + исходный код + метод научного тыка - в помощь"), которые постигают её.
Но система не для "избранных", а для масс. Отсюда и потребность материала с малым порогом вхождения
А вот веб-разработчик должен знать что делает, и специальное образование ему очень не помешает. Если нет некоего уровня знаний - надо его получать, но не требовать опустить планку. Знания нужны в любом случае. Но либо человек способен самообучаться, и тогда он всегда найдет помощь, потому что на конкретный вопрос можно дать конкретный ответ. Либо не способен, но под такое начинание нельзя подстаиваться, это тупик в будущем.
Мой пример с ГОСТом не так уж притянут за уши. Буквально несколько дней назад разбирал кастомизаию админки. Клиенту кто-то доделал статистику. Выбирается из БД несколько id, и потом для каждого в цикле свой запрос на полные данные. И спрашивают - а почему сервер виснет когда выбираем данные за три года?
А вы говорите - массы...
Таково свойство человеческой психики: нельзя получить насыщенный ответ, не накачав человека эмоциями.
По теме: сейчас одно из моих направлений деятельности в Юмисофте - это снижение порога входа в xslt, точнее в xslt+umi. Но не книгами и учебными курсами (этим занимается мой коллега), а готовыми примерами частей шаблонов и генераторами кода - как это сделано в некоторых фреймворках.
А проверять нас на вшивость (веб-разработчиков) как минимум не корректно, но раз данный пост имеет скрытый смысл, для выяснения интересующих вопросов разработчиков, то поддерживаю и рекомендую как можно скорее реализовать ваши задумки с примерами шаблонов и расширении документации.
Уважаю вашу команду вы сделали хороший продукт, в погоне за клиентами но слабо достаточно подошли к вопросу разработчиков ведь клиент только покупает а разработчик создает и воплощает его желания, так помогите нам по возможности всем чем сможете, что бы ЮМИ и в правду была самой гибкой и расширяемой платформой.
Успехов вам во всем. С уважением.
В отношении качества кода и тенденции падения. Есть два фактора.
php - не Марс. Это часть нашего реального мира. А что мы видим вокруг? ботинки с напылением кожи; ДСП с отделкой под дерево; синтетические ткани; еда, в которой не понятно чего больше - самой еды или химии с чудесами генной инженерии.. короче, суть одна - то самое г***, под красивой обложкой. Требование "рыночной экономики": делать больше и дешевле; а за счет чего можно делать дешевле - только за счет качества. Теперь добавим сюда распилы и откаты, ставшие нормой и даже не скрываемые. Было бы странно, если бы поколение, выросшее во всем этом, вдруг в php стало бы применять иные принципы.
С другой стороны, php имеет низкий порог вхождения, а web - стал самой доступной средой жизни. Поэтому сюда стало стекаться большое количество людей, которые не видят для себя применения в реальном мире; не потому, что они такие какие-то, нет, но такова политика современной России - обогащение кучки избранных, все остальное на грани выживания или за ней. Ну и куда людям деваться? - идут в интернет в надежде что-то заработать.
---
Лично мне, например, преимущества от xslt по-прежнему неочевидны. Преимущества есть для разработчиков cms, это да: получил данные, отправил их как xml, и все, не надо держать в голове блоки шаблонов, вносить изменения в двух местах при добавлении нового блока и т.п. Жизнь программиста упрощается, скрость разработки повышется, себестоимость снижается. А дальше уж ты, дорогой клиент xslt-верстальщик, разбирайся с нашим xml как знаешь, это твои проблемы.
Но для конечного потребителя tpl проще в освоении. А качество кода не зависит от шаблонизатора, а от квалификации разработчика.
Владимир, спасибо за отличный политически обоснованный комментарий. Но я, на основании своего 10-летнего опыта работы манагером в веб-студиях, хочу акцентировать внимание на том, что "сделать проект" - это половина дела. Да, можно быстро накодить и быстро сдать. Даже в Юми можно писать линейным кодом, прямо в шаблонах, вообще не задействуя ни TPL, ни XSLT. Но самые деньги лежат не тут. Они лежат в поддержке и развитии уже созданного проекта. Один из моих проектов претерпел 5 реинкарнаций, при этом нам в бюджет поступила сумма, которую некоторые веб-студии не зарабатывают за весь цикл своего существования. И клиент был счастлив. И вот чтобы взять эти деньги, нужно заложить правильный фундамент. Потому что если этого не сделать - на редизайне и развитии функционала кривая рентабельности пойдёт вниз ко всем чертям - в силу многократных переделок своего же кривого кода. Именно в этом заключается наш посыл использовать "правильные технологии", а не в банальном ускорении цикла "сделал-сдал".
Например, первая моя проблема, с которой я столкнулся, работая с xslt, был вопрос "Как же мне организовать структуру файлов с шаблонами, чтобы не запутаться в них", и как не организую, все равно путаюсь.
Так что, это все хорошо, но только для компаний, которые готовы заложить потенциал роста в разработку, а большинству это не надо или не выгодно.
Подытожив все выше сказанное...
Развивайте xslt, я полностью за это, но оставьте возможность работать с вашей системой и более простом варианте, на tpl. Либо... как было уже выше озвучено, создание инструментов и интерфейсов работы с xslt, чтобы позволить выполнять определенный уровень задач, легко и непринужденно))
P.S. еще раз повторюсь, что хотелось бы узнать, что именно вы делаете в этом направлении, чтобы я не дублировал ваши направления))
По поводу мотивации, к изучению. Я думаю, что если Юмисофт заинтересован именно в качественных веб-разработчиках, работающих на xslt, то следует провести курсы не именно по xslt шаблонизатору, а по той самой культуре вёрстке и плавно перейти к плюсам (скорость + качество, причём, всё-таки скорость на первом месте, т.к. для конечного заказчика качество реализации на tpl и xslt одинаково) разработки "кошерной" вёрстки именно на xslt. Чтоб представители студий, вернувшись в родные края хлопнули себя ладонью полбу и прозрели по поводу xslt.
1) Выдержка из вашей документации
<?xml version="1.0" encoding="UTF-8"?>
<xsl:stylesheet version="1.0" xmlns:xsl="http://www.w3.org/1999/XSL/Transform">
<xsl:output method="html" encoding="utf-8" />
<xsl:template match="/">
<html>
<head>
<title><xsl:value-of select="/result/@title" /></title>
</head>
<body>
<div id="main-menu">
<ul>
<xsl:apply-templates select="document('udata://content/menu')//item" mode="menu" />
</ul>
</div>
<div id="content">
<h1><xsl:value-of select=".//property[@name ='h1']/value" /></h1>
<xsl:value-of select=".//property[@name ='content']/value" disable-output-escaping="yes"/>
</div>
</body>
</html>
</xsl:template>
<xsl:template match="item" mode="menu">
<li>
<a href="{@link}"><xsl:value-of select="." /></a>
</li>
</xsl:template>
</xsl:stylesheet>
2) Эквивалентная перефразировка в "неправильных" терминах, без xslt
<html>
<head>
<title><?=$page->title?></title>
</head>
<body>
<div id="main-menu">
<ul>
<?$menu=getContent('menu'); foreach( $menu as $item ): ?>
<li>
<a href="<?=$item->link?>"><?=$item->text?></a>
</li>
<?endforeach?>
</ul>
</div>
<div id="content">
<h1><?=$page->h1?></h1>
<?=$page->content?>
</div>
</body>
</html>
ok?
</code>
or so?
1) Выдержка из вашей документации
<?xml version="1.0" encoding="UTF-8"?>
<xsl:stylesheet version="1.0" xmlns:xsl="http://www.w3.org/1999/XSL/Transform">
<xsl:output method="html" encoding="utf-8" />
<xsl:template match="/">
<html>
<head>
<title><xsl:value-of select="/result/@title" /></title>
</head>
<body>
<div id="main-menu">
<ul>
<xsl:apply-templates select="document('udata://content/menu')//item" mode="menu" />
</ul>
</div>
<div id="content">
<h1><xsl:value-of select=".//property[@name ='h1']/value" /></h1>
<xsl:value-of select=".//property[@name ='content']/value" disable-output-escaping="yes"/>
</div>
</body>
</html>
</xsl:template>
<xsl:template match="item" mode="menu">
<li>
<a href="{@link}"><xsl:value-of select="." /></a>
</li>
</xsl:template>
</xsl:stylesheet>
2) Примерно эквивалентная перефразировка в "неправильных" терминах, то есть без xslt
<html>
<head>
<title><?=$page->title?></title>
</head>
<body>
<div id="main-menu">
<ul>
<?$menu=getContent('menu'); foreach( $menu as $item ): ?>
<li>
<a href="<?=$item->link?>"><?=$item->text?></a>
</li>
<?endforeach?>
</ul>
</div>
<div id="content">
<h1><?=$page->h1?></h1>
<?=$page->content?>
</div>
</body>
</html>
(Прошу меня извинить и удалить лишнее, кнопки HELP ннгде на этой странице не нашёл, но очень хотелось высказаться. Пришлость устроить небольшой бета-тест этому блогу)
Да и разговоры про TPL vs XSLT уже должны в прошлом остаться. И так все ясно. Лучше напишите про XML vs JSON - это гораздо интереснее и перспективнее. Многие разработчики необоснованно забывают про это преимущество UMI.CMS!
А TPL просьба оставить для визарда быстрого создания сайта. Там ему самое место.
А на счет вопроса о гибкости. Мне кажется любой, кто после tpl переходит на XSLT шаблоны, говорит: Это-же круто! Это гораздо удобнее и мощнее! Я реально быстрее собираю сайт! Я могу создать свою логику для обработки данных, для создания сложных меню, для обработки условий, например вывода различного контента. Мне проще обработать данные, какого-бы формата они не были. Мне больше не нужно использовать по пустякам PHP кастомизацию.
А потом он думает... Ё! Но как-же научить моих коллег? Не... Не будем терять время, (время - деньги) - пусть делают на tpl. И будем считать, что это быстрее...
Обращается ко мне однажды клиент. Ему сделали сайт на xslt. все хорошо, но вот захотел он добавить новый раздел. Скопировал аналогичный, и глядь - а там нет внутреннего меню! Вот нет и все. Открываю шаблон и вижу картину маслом, даже сливочным:
<xsl:when test="$pageId = 202 or $pageId = 207 or $pageId = 188 or $pageId = 374 or $pageId = 185 or $pageId = 200 or $pageId = 863">
<xsl:call-template name="navi.submenu">
<xsl:with-param name="pageForLeftMenuId" select="$pageId"></xsl:with-param>
</xsl:call-template>
</xsl:when>
Ну и где же масштабируемость?
А потом он думает... Ё! Но как-же научить моих коллег?
В данном случае, мне кажется, лучше бы это сделали старшие товарищи из ЮМИ. Как? Ну меня бы устроила вот такая табличка со сравнительными достоинтствами и недостатками.
Я видел сайты и без вывода мета-данных keywords и description. И что? Теперь я должен решить что на XSLT писать плохо? Вовсе нет.
И зачем нужна таблица? Нет полного соответствия между шаблоном на tpl и XSLT. Попытка сделать такую таблицу для простых решений тоже будет неудачной, так как проще сделать основу именно на XSLT. И нет необходимости писать каждый раз код заново.
Это как попытка сравнить гвоздь и винт. Некоторые и винты молотком забивают (Ваш пример на XSLT), но от этого преимущества винта перед гвоздем для строителя "с головой" не уменьшаются.
Необходимости писать код заново нет в любом случае. Однажды заготовленные файлы с кастомами просто копируются и сразу готовы к использованию.
Лично мне проще написать на XSLT, чем писать кучу кастомов под каждый нестандартный запрос клиента. А потом, если потребуется, писать изменение для кастома и следить, чтобы это не привело к ошибке для прежнего решения.
Когда можно проще написать пару строк на XSLT и решить задачу.
Также на XSLT мне будет проще найти ошибку в коде, чем с использованием кастомов.
Правильно, и я о том-же, что писать заново код нет в любом случае. Поэтому неважно сколько строк в коде, так как он все равно копируется.
И я уже не говорю про легкость тестирования выполнения макросов на XSLT и нахождения "узких мест" в работе сайта.
Проблема не в том, что сайт на XSLT шаблоне лучше и удобнее, проблема в том, что некоторые разработчики делают деньги на tpl сайтах и не видят причин, для чего им нужно учить еще и XSLT. И вот Юми, спасибо им за это, делают кроме CMS, еще и просветительскую работу. И это правильно и важно!
Вот как раз к просветительской работе. Вам нравится xslt - очень хорошо. Но чтобы доказать как он хорошо другим, нужно это как-то обосновать. Критерием обоснованности может быть снижение трудоемкости при разработке и модификации. Но нужно тогда показать это снижение! Вопрос даже не в квалификации, квалификация будет, всегда можно научиться, было бы ради чего. Но ради чего? А пока получается парадоксальная ситуация: периодически возникают утверждения о правильной технологии, но когда дело до конкретики, оказывается, что кроме общих фраз ничего не говорится(
В xslt нравится сама идея отделения php-логики от оформления результата; я даже согласен, что этот путь - наше светлое будущее, как коммунизм. Но одно дело - идеология, и другое - практика. Практика мне говорит, что tpl нагляднее и легче воспринимается. Не так? Хорошо. Но тогда, товарищи сторонники xslt, вы можете показать на примерах конкретно? Если нет - тогда зачем заводить разговор в ключе "эта технология лучше другой"?
Допускаю, что такие примеры приводились и я их проглядел. Тогда не обессудьте за резкость и кинеть, пожалуйста, ссылочку где посмотреть?
http://blog.umi-cms.ru/dmitrij_babanov1/zadat_vopros_svoemu_menedzheru/
http://blog.umi-cms.ru/dmitrij_babanov1/manager_block_random1/
http://blog.umi-cms.ru/kirill_sidorov/karusel_tovarov/
Попробуйте сделать то-же самое на tpl, PHP, включая выборки... Например можно самому написать запрос с помощью api.
Но стоит-ли?
Но поскольку нам пообещали долгую жизнь tpl-шаблонизатору, то предмет дискуссии сам собой снимается)
Есть sky911.ru где посещаемость около 14000 в день. Более посещаемых не знаю. Сам бы с интересом посмотрел
....а... так там же счетик не показывает количество посетителей, откуда ж узнать что там 100 000.
Но все равно - запомним как пример) Спасибо
А в самом посте я даже сделал оговорку про код в шаблонах в highload-проектах: там самый быстрый шаблонизатор - это линейный php-код в шаблонах, и ничего тут не сделаешь.
Так что наш посыл - не столкнуть лбами людей, а дать им максимум информации и снизить порог входа. Чем мы и занимаемся каждый день :)
Тут уж не то что про tpl не говорится, а даже напротив, исключается. Или я что-то не понял?
XSLT - какашка, ненаглядная какашка для либо теоретиков, либо для накручивающих себе рейтинг вебстудий (которые делают за 100% оплаты 80% работ по сайту, требущих 20% от общего времени на разработку. Основная маржа идёт за дизайн, вёрстка тоже более-менее ценится, а программирование, оно только время жрёт, потому может сделают заказчику 1-у фичу из 20, что он просил, ну а за xslt просто лапшу удобно навешать клиенту).
Всё... Через полгода заказчик изучил, то что ему наклепали, сравнил с тем, что он хотел на сам деле, увидел, что многое из этого реализованно на других сайтах и ему становится трэба дороботок.
И вот тут он попал. И на tpl то не найдёшь никого на доработку, а уж на xslt тем паче, ибо дураков всё меньше... Чем ломать себе голову, легче за это время типовой сайт на юми поднять.
Так что в итоге XSLT реализация обрекает изначальная сайт на стогнацию и почти исключает его дальнейшее развитие.