Pull to refresh

Comments 54

Для топика на хабре, не важно какого по счету, желательны живые примеры, разные методики и технологии, свои комментарии к этому и пояснения. А так это просто первый абзац книги «XSLT для чайников», не несущий никакой полезной нагрузки.
Сам в начале изучения всех прелестей xslt:)
Буду рад если кому-то будет полезен этот топик, хотя бы для общего представления, ибо не так уж много информации(примеров) по применению :(
Посмотрите cms HostCMS, она построена по похожему принципу. (т.е. перед выводом все данные в xml)
Для полноты картины попробуйте в правом верхнем углу найти поле для поиска, ввести туда XSLT и нажать кнопку справа. А так же выполнить нехитрый запрос к гуглу «XSLT site:habrahabr.ru». Вы удивитесь кол-ву найденных сломанных копий в прошедших холиварах, а так же множеству полезных статей, которые уже давно есть на хабре.
Просто, чем превращать хабр в банальный форум «для чайников», попробуйте освоить поиск, либо поучаствовать в фуршете, который два дня назад открылся, либо поискать прошлые фуршеты, уж точно в одном из них были спецы по XSLT, которые с готовностью вам помогут.
Учитесь думать, а не спрашивать :)
Спасибо за критику… теперь буду умнее…
Одна голова хорошо, а две лучше…

Из всего что видел на хабре… по существу не смог ничего найти именно по тому направлению о котором я сказал… видимо слепой:(
-Отдавать надо только html, ибо парсить xslt вменяемо умеет только осёл.
-Предпочтительно использовать то, что умеешь.
-Это решать уже вам.
по 1п. а если же использовать простейшие шаблоны? вот только еще не знаю как к этому отнесутся поисковики :(
Кстати, и для поисковиков засада, да…
ИМХО, лучще уж парсить на сервере…
>Отдавать надо только html, ибо парсить xslt вменяемо умеет только осёл.
Ваши данные не совсем верные.
1. Даже опера научилась делать XSLT — преобразования
2. Ни один из броузеров не может выполнять XSLT по полной программе. Все делают это криво.
Долгое время использовал xml+xslt в своих приложениях. По скорострельности выгоднее использовать преобразование xml посредством браузера (сейчас, если не ошибаюсь, это умеют все браузеры).
Но, опять же по скорострельности, лучше использовать html+php, так как генерация xml занимает довольно немало времени — на «больших» сайтах это будет довольно накладно по ресурсам системы и скорости загрузки страницы.
Когда я пробовал передавать ф-ии парсинга шаблонов на браузер, то получилосб это только с IE. Может, я конечно, заблуждаюсь… но…

Один их "+" XML в том, что его удобно кешировать, во всяком случае в моей реализации…
Точно умеет ФФ, только что проверил.
Да, огромнейший плюс такой реализации, это тот факт, что фактически кеширование будет на уровне страницы, а не на уровне запросов, форм и т.д.
это хорошо, но как гуглояндексы отнесутся к этому?
Ну как вариант, может можно для роботов отдавать хтмл?
Плохо отнесутся =)
Для этого можно сделать отдельное правило, если зашел поисковик — отдаем браузеру html, иначе xml
Но, ИМХО, слишком это заумно =(
Это не заумно. Это — маразм и верный путь в бан.
Чтобы все индексировалось нормально нужно сделать дополнительное преобразование см. www.erum.ru/article/16
Вот примерчик с wiki выдергивал… работает под ie6, opera 9.6, ff
spasibo.biz/document.xml

проблем с парсингом вроде нет… но здесь простейший пример…
если при нативных пхп-шаблонах цепочка выглядит как
controller -> model -> data-> view -> html
то при xslt цепочка выглядит как
controller -> model -> data-> xml -> view(xslt) -> html

Один лишний шаг, плюс вопросы с производительностью xslt — библиотек

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

звена «data» можно избежать, если изначально оперировать с xml
оперировать с xml, конечно, можно, причем забирая данные из базы сразу в xml-виде.
но на уровне реализации бизнес-логики придется доставать данные используя xpath или курсируя по DOM, что значительно утяжелит приложение.

но для сценарив без логики «достал — показал» вполне сгодится.
и опять же в минус производительности
ну если уж по такой логике, то цепочка «быдлокод → html» еще короче.
там где это оправданно — да.
не стоит плодить лишних сущностей там, где это не нужно.
Blizzard'ы на своих сайтах используют xml+xslt
спасибо, это плюс для меняы в сторону применения xml+xslt :)
Одна из идей топика это возможность написания web-приложения на любом языке, например:
— MC — asp, php
— парсер — С, php
— ну а шаблоны независимы получаются…
ну ет для больших проектов :)
В общем начитался я интервью яндекса хабру :)

имхо. Но идея глобальная:)
Хм… ну еще как вариант…
Если можно использовать разную реализацию, то соответственно можно выбирать наиболее производительную…
Имхо, если использовать XSLT, то отдавать пользователю xml и шаблон, иначе один из главных плюсов(один раз отдать шаблон) теряется.
М. Фаулер, «Архитектура корпоративных приложений», Глава 14, Transform View + Two-Step View.
Если Вам интересно, то как пример CMS с использованием XSLT могу привести свой Explay (http://explay.su). Код, само-собой, весь открытый и бесплатный.

Лично мне XSLT нравится своей красотой :) да и при его использовании требования к качеству архитектуры движка намного повышаются.
Мне кажется это решение будет сильно проигрывать по производительности обычным шаблонизатором.
Передавать XML+XSLT клиенту вообще говоря нельзя. Ни один броузер не умеет нормально обрабатывать XSLT. От многого приходится отказываться. Например от DOCTYPE. Но если что-то несложное по структуре и дизайну то вполне можно. Примеры сайтов на клиентском XSLT:
www.x9.ru
www.erum.ru
чем доктайп помешал? о_0
Наоборот. Я так и не нашел способа задания DOCTYPE на клиенте.
xsl:output doctype-public="-//W3C//DTD XHTML 1.0 Strict//EN" doctype-system=«www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd»
Игнорируется.
Или что-то не то делаю?
если проблема в квиркмоде в ие, кто скорее всего у тебя инструкции процессору копируются…
В квиркмоде проблемы нет. Есть проблема вывести с нормальным DOCTYPE и эта проблема была во всех броузерах. Впрочем, больше года в эти игры не играл. Может что-то изменилось но уж точно не в IE6.
куда вывести? доктайп влияет только на режим рендеринга.
По шагам:

1) Отдаю XML броузеру. Указать там DOCTYPE нельзя
2) Делаю XSLT преобразование и в нем пытаюсь задать DOCTYPE результата через xsl:output, но
DOCTYPE в результат преобразования скорее всего не выводится — все работает в квиркмоде

Т.е. я так и не понял можно ли на клиенте задать DOCTYPE для финального документа или нет.
1. а он там и нафиг не сдался
2. rendol.habrahabr.ru/blog/66774/#comment_1881492
коммент, не подкреплен фактами:
делали проект на хслт, результат запроса в БД транслировался в ХМЛ и инклудился в общий ХМЛ документ
как парсер — нгинкс
так вот, на первый взгляд — производительность с включенным ХСЛ и выключенным — разнилась процентов на 20
не проверяли как быстро работает хсл трансформация в пхп, или доморощенные шаблонизаторы

разделяемость труда повысилась на несколько порядков, гибкость возросла до небес, а от красоты подхода кончили всей командой
> результат запроса в БД транслировался в ХМЛ и инклудился в общий ХМЛ документ
Можно сэкономить если отдельные части кэшировать после XSLT, а на финале только собирать куски через тот же xslt
Заодно на финале можно прикручивать конечный дизайн.
ну я вам всю систему в одном каменте не распишу )
там много чего кешируется, кеш достаточно умный
и после хслт не удастся, нгинкс принимает хмл — выдает хтмл клиенту
как раз вопрос производительность хсл преобразования не стоял, оно достаточно быстрое и понятно как масштабируется на базе нгинкса

до этого, да, были вопросы: вся страничка была поделенна на н блоков, каждый из которого кешируется, кешируется с учетом кто зашел, когда, инвалидация кеша итп… кароче, много ньюансов
«Петька, что бизнес-логика?»
ну вы говорите что запрос БД транслируется в XML и отрисовывается XSLT, я так понял что такая вещь как контроллер (екшен и т.п.) не используется как класс, так а где вы описываете поведение системы и ее объектов? поскольку если контроллер таки используется то в чем соль? какая разница отдавать во вью структуру xml-ем или массивом? от чего кончали-то?
я вам на пальцас рассказал, как его делали
всю картину — долго рассказывать
кончали от простоты подхода, скорости разработки, скорости работы и красоты конечного технического решения
у XSLT много преимуществ но есть 2 недостатка:
1. Медленность, особенное в случае php — нет поддержки компилируемых таблиц
2. Многословность, Вас за… т раньше чем напишете что-то действительно серьезное
3. Нет побочных эффектов, да это красиво но на практике доставляет нипадецки и плодит решения дикой избыточности и сложности… аля мне нужно в шаблоне сделать нумерацию от 0 до 9 (цикл)… я знаю решение, оно у меня записано на бумажечке но я вжись сам его не воспроизведу.

Если Вам нравится XSLT и используете PHP посмотрите в сторону PHPTal — ссылку не даю сознательно, это порт питоновского TAL и это феерическая штука для фанатов XSLT только попроще.
еще добавлю… эйфория XML+XSLT была 2 года назад (Apache Cocoon) но сошла на нет, вот Вам ответ стоит-ли, в каких-то ситуациях безусловно стоит но это не подход в веб-разработке претендующий на успешность однозначно (для меня)
Sign up to leave a comment.

Articles