1) давайте пример данных, я вам приведу пример реализации
2) я имел в виду разработчиков
3) вот именно что грамотный, только вто зачастую качество девелопмента страдает...
4) обоснуйте
5) и что для каждого языка теперь учить новый шаблонизатор?
6) в ряде случаев это не увеличение, а снижения трафика + что вы понимаете под словом слабой?
иногда я накладываю XSL на файлы более 200м, там каждый процент производительности важен... а других способов решить задачу просто нету, вот по этому и спрашивал.
я не говорю про то что PHP медленный, я говорю что XSL достаточно быстр
из глюков я встречал только два (в Saxon):
1) for-each-group груп не работает со сложным группировочным XPath выражением
2) for-each-group не умеет разбивать блоки текста в группы по br
скорость у XSL нормальная, вот к примеру у меня есть небольшой сайт (примерно 3100 страниц) (для экспериментов по обработке данных) он собирается из одного XML файла (15мб) одним XSL преобразованием примерно за 21с, собирается саксоном, а он не самый быстрый XSL процессор.
Полутора недель на освоение XSLT, разумеется, не достаточно. Хотя там всего-то десяток употребительных конструкций. Через полторы недели, как правило, верстальщик начинает писать код "как-на-смарти". Ну или как на PHP. Один шаблон, пачка вложенных for-each, ветвление через choose где ни попадя, дублирование кода и прочие радости. Много раз такое видел.
для достижения этого уровня достаточно и трех дней...
я видел не один десяток XSLT разработчиков которые достигали этого уровня за 3 дня
иногда люди за три дня успевают разобраться в групперовке
Есть уже, только не здесь
http://clubs.ya.ru/4611686018427388239/ - здесь порядка 50 профессиональных XSLT разработчиков
только они как правило темы о XSLT обсуждают не в блоге, а в курилке...
1) группировка с сортировкой тривиальна, лично для меня таковой планкой полное понимание механизма группировки мюнха.
2) кому как
3) кто ищет тот всегда найдет, есть люди которые активно делятся своим опытом и помогают у обучении новичкам
4) чем вам качество не угодило?
в том то и дело что у смарти есть привязка к PHP, и если у вас в команде есть верстальщик который знает смарти то что бы он сделал шаблон к примеру для сервера на JAVA или C++ или чего угодно ему нужно учить новый шаблонизатор
а XSL верстальщик может сделать шаблон к любому бекенду, даже не особо задумываясь какие технологии там используются, есть лишь небольшие различия в различных диалектах XSLT процессоров
1) XSL шаблон не настолько больше весит, а при правильном проектировании может весить и меньше
2) XSL просто читается что повышает скорость его чтения
3) XSL хорошо структурирован, что позволяет просто навигироваться даже в большом шаблоне
4) увеличение размера шаблона лишь косвенно может увеличить время на разработку
5) XSL есть практически везде, что позволяет использовать XSL разработчиков практически во всех задачах требующих отображения данных, начиная от построения отчетов заканчивая сложными JavaScript приложениями что сокращает расходы
6) XSL можно накладывать на клиентской стороне, что сильно экономит серверные ресурсы и снижает расходы на эксплуатацию проекта
как не странно но на том же ClientSide 2007, в секции шаблонизаторов был только XSLT
а вообще нужно понимать за что вы платите и что вы эконовите, в случае XSL вы платите больше за серверные ресурсы, но при этом сокращаете затраты человеческого времени на разработку и поддержку
2) почему шаблон не должен быть примитивным? это веть на оборот хорошо!
пример среднего размера, примеров с большой посещаемостью испрользующих XSL под рукой нету
яндекс это не 100% XSL (есть вещи где нету XSL, к примеру на морде www.yandex.ru)
2) я имел в виду разработчиков
3) вот именно что грамотный, только вто зачастую качество девелопмента страдает...
4) обоснуйте
5) и что для каждого языка теперь учить новый шаблонизатор?
6) в ряде случаев это не увеличение, а снижения трафика + что вы понимаете под словом слабой?
ya.ru
market.yandex.ru
fotki.yandex.ru
три крупных проекта, и все используют во фрондендах XSL
*.yandex.ru
*.ya.ru
ЗЫ
конкретные проекты лень перечислять
2) фронтенды которые занимаются шаблонизацией просто и эффективно кластеризуются
так что унификация не всегда приводит к потерям в скорости.
я не говорю про то что PHP медленный, я говорю что XSL достаточно быстр
1) for-each-group груп не работает со сложным группировочным XPath выражением
2) for-each-group не умеет разбивать блоки текста в группы по br
скорость у XSL нормальная, вот к примеру у меня есть небольшой сайт (примерно 3100 страниц) (для экспериментов по обработке данных) он собирается из одного XML файла (15мб) одним XSL преобразованием примерно за 21с, собирается саксоном, а он не самый быстрый XSL процессор.
думаете на PHP + смарти было бы быстрее?
для достижения этого уровня достаточно и трех дней...
я видел не один десяток XSLT разработчиков которые достигали этого уровня за 3 дня
иногда люди за три дня успевают разобраться в групперовке
http://clubs.ya.ru/4611686018427388239/ - здесь порядка 50 профессиональных XSLT разработчиков
только они как правило темы о XSLT обсуждают не в блоге, а в курилке...
2) кому как
3) кто ищет тот всегда найдет, есть люди которые активно делятся своим опытом и помогают у обучении новичкам
4) чем вам качество не угодило?
а XSL верстальщик может сделать шаблон к любому бекенду, даже не особо задумываясь какие технологии там используются, есть лишь небольшие различия в различных диалектах XSLT процессоров
2) XSL просто читается что повышает скорость его чтения
3) XSL хорошо структурирован, что позволяет просто навигироваться даже в большом шаблоне
4) увеличение размера шаблона лишь косвенно может увеличить время на разработку
5) XSL есть практически везде, что позволяет использовать XSL разработчиков практически во всех задачах требующих отображения данных, начиная от построения отчетов заканчивая сложными JavaScript приложениями что сокращает расходы
6) XSL можно накладывать на клиентской стороне, что сильно экономит серверные ресурсы и снижает расходы на эксплуатацию проекта
а вообще нужно понимать за что вы платите и что вы эконовите, в случае XSL вы платите больше за серверные ресурсы, но при этом сокращаете затраты человеческого времени на разработку и поддержку