Хабр Курсы для всех
РЕКЛАМА
Большая витрина: от крупнейших школ до частных авторов. Сравнивайте по цене, длительности, формату и выбирайте самый подходящий курс!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 132
а можно обрабатывать xslt на стороне сервера и тогда и инклуды будут срабатывать и мобильным и прочим браузерам будет отдаваться нормальная страница.
правда мы на своем проекте используем xslt для шаблонизации, но для инклудов используем
правда мы на своем проекте используем xslt для шаблонизации, но для инклудов используем
сборка на клиенте позволяет задавать разные параметры кэширования для разных частей страницы. например, тяжёлый статический сайдбар не нужно грузить с каждой страницей.
с этим согласен.
но все-же считаю необходимым дополнить что, возможно, часть инклудов стоит обрабатывать на стороне сервера, чтобы не нагружать лишний раз компьютер пользователя.
правда, я сам лично пока ни разу не сталкивался со страницами с тяжелыми статичными сайдбарами, но согласен с тем, что если большая часть страницы собирается из тяжелых статичных вещей то подход сбора страницы на строне клиента вполне оправдан.
но все-же считаю необходимым дополнить что, возможно, часть инклудов стоит обрабатывать на стороне сервера, чтобы не нагружать лишний раз компьютер пользователя.
правда, я сам лично пока ни разу не сталкивался со страницами с тяжелыми статичными сайдбарами, но согласен с тем, что если большая часть страницы собирается из тяжелых статичных вещей то подход сбора страницы на строне клиента вполне оправдан.
у кого-то серьёзные проблемы с семантикой русских слов…
тут имеется в виду клиентское кеширование некоторых частей. например если человек читает статью и обновляет страницу — не обязательно его заставлять по новой качать всю статью, можно просто на сервере отдавать блок «статья» с соответвующими заголовками — чтобы клиент не перекачивал статью по новой, а просто обновлял комменты, а статья подтягивалась и инклудилась из кеша браузера.
короче для крупных статичных блоков подход действительно применим, а троллите вы довольно толсто
короче для крупных статичных блоков подход действительно применим, а троллите вы довольно толсто
>для таких вещей есть аякс + вебсокеты. а писать вычурно это глупо.
Вычурно собирать статическую страницу через Javascript.
А сборка статической страницы через XSLT выглядит очень даже естественно.
Вычурно собирать статическую страницу через Javascript.
А сборка статической страницы через XSLT выглядит очень даже естественно.
конечно можно. но это для случая когда сидишь на странице и жмёшь кнопку «ещё комментов». а я вот получаю уведомление на почту, и гружу страницу целиком.
например какая динамика? рзумеется не всё имеет смысл кэшировать. например прямой эфир на активно посещаемом сайте кэшировать бессмысленно.
в топку хтмл — давайте всё писать на чистом яваскрипте ;-)
например какая динамика? рзумеется не всё имеет смысл кэшировать. например прямой эфир на активно посещаемом сайте кэшировать бессмысленно.
в топку хтмл — давайте всё писать на чистом яваскрипте ;-)
Статикой в данном контексте я называю статический HTML. В отличие от Dynamic HTML. В первом нет интерактивности. Во втором есть. Если нет интерактивности (DHTML) использование JS выглядит противоестественно.
> единственная тема где xslt реально место и он там очень в тему…
> так это как прослойка для формата данных отдаваемых одним серваком другому…
XSLT место там где один XML преобразуется в другой. Не пофиг откуда куда XML гонится? Да хоть курьером на 5"-дискете
> единственная тема где xslt реально место и он там очень в тему…
> так это как прослойка для формата данных отдаваемых одним серваком другому…
XSLT место там где один XML преобразуется в другой. Не пофиг откуда куда XML гонится? Да хоть курьером на 5"-дискете
каждая легушка свою кочку хвалит
Вот приведите мне пожалуйста + и — вашего метода против аякса/вебсокетов тогда и поговорим
Если прочитать пост не через строку, то вы найдёте ответ на вопрос о плюсах и минусах
плюсы и минусы — это сильно субъективные понятия. для кого-то использование xslt — это минус, а кому-то пофиг. кого-то не смущают скачки в процессе загрузки страницы, а кого-то они раздражают. я описал технологию и её особенности. если влом в ней разбираться — я тут ничем помочь не могу.
Если вы не хотите читать, почему это должен делать кто-то другой и потом вам рассказывать? Зачем вообще заходить в пост и оставлять комментарии, если вы его не читали?
прикольно, но мутно. а вот еще один вариант клиентского include реализованного на javascript
Мы для включения других файлов использовали XInclude.
Просто и как Ленин завещал :-)
Просто и как Ленин завещал :-)
а также xlink, но всё это богатство имеет непрактичный синтаксис и не поддерживается браузерами.
Насчёт непрактичного синтаксиса спорить не буду, как говорится, suum cuique, а вот поддержки браузеров нет, это правда.
В своё время выбрали серверную обработку XSLT и сопутствующие вкусности, добавили кеширование и вуаля…
Опять же, каждому своё.
В своё время выбрали серверную обработку XSLT и сопутствующие вкусности, добавили кеширование и вуаля…
Опять же, каждому своё.
не, ну писать [xi:include href="..."][xi:fallback]...[/xi:fallback][/xi:include] слишком муторно
У нас была программная обработка и формирование главных шаблонов на уровне серверного языка (PHP), поэтому сами такое не писали. «Рядовые» программисты писали XSL (и частично XML) для отдельных модулей/действий.
А вообще, связка XML/XSLT и так довольно муторна — иногда для одного HTML тега столько наворотишь.
Но гибкая и требует грамотного подхода, абы как не сделаешь.
За что до сих пор и люблю. :-)
А вообще, связка XML/XSLT и так довольно муторна — иногда для одного HTML тега столько наворотишь.
Но гибкая и требует грамотного подхода, абы как не сделаешь.
За что до сих пор и люблю. :-)
Круто!
Примеров, где можно было описанное применить на практике, мне кажется, не хватает.
Причем очень. Зачем все эти свистопляски с инклудами?
выше привели пример зачем нужны инклуды на стороне клиента —
сборка на клиенте позволяет задавать разные параметры кэширования для разных частей страницы. например, тяжёлый статический сайдбар не нужно грузить с каждой страницей.
вообще смысл в том что шаблоны вашего сайта разбиваются на отдельные блоки (шапка, меню, футер и т.д.) и эти блоки вставляются в необходимое место на странице. в случае если в блоке какое то тяжелое статичное содержимое то вставляться можно на стороне клиента чтобы содержимое кешировалось (ну и естественно необходимо правильно на стороне сервера отдавать заголовки для нужных блоков, одним клиентским инклудом тут не обойдешься), а какие то мелкие блоки можно инклудить прямо на сервере обрабатывая xslt
собственно, любой более-менее приличный шаблонизатор умеет инклудить шаблоны, это просто один из способов — клиентские инклуды
сборка на клиенте позволяет задавать разные параметры кэширования для разных частей страницы. например, тяжёлый статический сайдбар не нужно грузить с каждой страницей.
вообще смысл в том что шаблоны вашего сайта разбиваются на отдельные блоки (шапка, меню, футер и т.д.) и эти блоки вставляются в необходимое место на странице. в случае если в блоке какое то тяжелое статичное содержимое то вставляться можно на стороне клиента чтобы содержимое кешировалось (ну и естественно необходимо правильно на стороне сервера отдавать заголовки для нужных блоков, одним клиентским инклудом тут не обойдешься), а какие то мелкие блоки можно инклудить прямо на сервере обрабатывая xslt
собственно, любой более-менее приличный шаблонизатор умеет инклудить шаблоны, это просто один из способов — клиентские инклуды
Спасибо. Я Понял ответ. Однако по моим оценкам «тяжесть» может выражаться в чем? Много верстки?* Я сомневаюсь, что количество верстки реально станет таким огромным, что на этом будет иметь смысл экономить, тем более такими трудными в написании (в сравнении с plain HTML) способами.
Кроме верстки всё остальное кешируется и так.
Кроме верстки всё остальное кешируется и так.
а в чём сложность написать постфильтр, который будет оборачивать произвольный хтмл в хслт?
Простите, я не понял вопроса про оборачивание XHTML в XSLT. По всем моим знаниям: XSLT — это набор правил, который применяется к XML-ю (частным случаем которого является XHTML) XSLT-парсером. Парсер выдает на выходе другой XML.
Про оборачивание XML в XSLT ничего не знаю.
Про оборачивание XML в XSLT ничего не знаю.
ты внимательно почитай. html заворачивается в xslt-контейнер, который сам себя распаковывает и возвращает html с уже подключёнными внешними файлами.
Так выражайся сразу по людски и перечитывать не придется. Можно обернуть. сопустствующий геморрой нафиг не нужен.
для web-приложений имеет смысл. Для обычных сайтов не надо.
для web-приложений имеет смысл. Для обычных сайтов не надо.
ну, вообще говоря, не только для веб приложений — например для сайтов, на которых выкладываются длинные новости, тоже можно применить местами — сделать блок новости чтобы подгружался таким способом, а на сервере новость отдавать с заголовком expires на полгода вперед, и тогда когда посетитель будет снова заходить на сайт у него новость не будет снова подгружаться — сайт будет работать с точки зрения посетителя «быстро» => повышается лояльность
таким же образом можно подгружать большие блоки, как например, список категорий на www.alibaba.com/ — они есть справа почти на каждой странице и он почти никогда не меняется => один раз отдал его клиенту с большим expires и снизил нагрузку на свой сервер и ускорил загрузку страницы у клиента.
применений можно найти множество
таким же образом можно подгружать большие блоки, как например, список категорий на www.alibaba.com/ — они есть справа почти на каждой странице и он почти никогда не меняется => один раз отдал его клиенту с большим expires и снизил нагрузку на свой сервер и ускорил загрузку страницы у клиента.
применений можно найти множество
я специально так сделал, чтобы небыло никакого геморроя ввинчивать в уже существующую инфраструктуру =_=" сам бы я делал несколько по другому, разумеется… с большим «геморроем»
Чтобы переписать готовый сайт, например писанный на zend framework, под эту оптимизацию нужно немало попотеть.
новый проект писать сразу с учетом — это другое дело.
в общем как и везде — оптимизировать нужно с умом, а не пихать просто так куда попало.
новый проект писать сразу с учетом — это другое дело.
в общем как и везде — оптимизировать нужно с умом, а не пихать просто так куда попало.
что как бы намекает о качестве этого фреймворка ;-)
тут имеется в виду что вы 1 раз разрабатываете шаблон, который будет превращать ваш plain html в этот «трудный в написании» код и далее уже полученный код вы используете на сервере или на клиенте.
т.е. вы пишете так сказать «компиллятор шаблонов», вещь, которая есть во многих шаблонизаторах, и которая работает так:
1. вы пишете ваш шаблон на чистом xHtml
2. при первом заходе посетителя на страницу или вы вручную заставляете компиллятор превратить ваш plain html шаблон в xslt шаблон
3. полученный xslt шаблон используете дальше где нужно, при изменении plain html шаблонов — просто перекомпиллируете.
писать сразу такие шаблоны как предлагается в топике — да, сложно.
Написать преобразование для превращения в такой шаблон обычного html — не сложно.
как то так
т.е. вы пишете так сказать «компиллятор шаблонов», вещь, которая есть во многих шаблонизаторах, и которая работает так:
1. вы пишете ваш шаблон на чистом xHtml
2. при первом заходе посетителя на страницу или вы вручную заставляете компиллятор превратить ваш plain html шаблон в xslt шаблон
3. полученный xslt шаблон используете дальше где нужно, при изменении plain html шаблонов — просто перекомпиллируете.
писать сразу такие шаблоны как предлагается в топике — да, сложно.
Написать преобразование для превращения в такой шаблон обычного html — не сложно.
как то так
очень пригодится при реализации современных динамических приложений подобные www.netvibes.com/, где интерфейс собирается из разных независимых блоков
данная страница состоит из 2 частей: объёмная статья и много комментов. сейчас сделано так, что комменты подгружаются аяксом из-за чего мы наблюдаем неприятный скачок между загрузкой статьи и загрузкой комментов.
инклуды создадут другие проблемы и неудобства.
какие?
кеширование имеет недостатки которые растут из достоинств.
для программера — усложнение программирования динамического контента, чтобы учесть эту оптимизацию
для программера — усложнение программирования динамического контента, чтобы учесть эту оптимизацию
Программеру все равно придется заниматься кэшированием и оптимизацией динамического контента. Только при выносе сборки различных динамических блоков голова у него болеть будет меньше. Да и нагрузка на сервер так же будет меньше.
Усложнения возникают, лишь когда архитектура приложения была продумана ммм… мягко скажем, не очень хорошо.
ну я не соглашусь.
xslt на стороне сервера это отличное решение для шаблонизации.
работает он быстро, я бы не сказал что медленее чем тот же смарти или другие шаблонизаторы.
+ xslt позволяет снять часть задачи с php и некоторые вещи генерируются с использованием xslt очень удобно и просто (например локализованные версии сайта).
+xslt никогда не даст тебе оставить не закрытым тег :) и вообще писать html шаблоны с сипользованием xslt — хорошая практика для программистов, по началу возникают проблемы как писали выше мол «иногда для одного HTML тега столько наворотишь.», но с набором опыта проблема решается и учишь верстать красивее и писать более красивые xslt шаблоны, без лишних наворотов.
и он очень изящный, кстати :)
xslt на стороне сервера это отличное решение для шаблонизации.
работает он быстро, я бы не сказал что медленее чем тот же смарти или другие шаблонизаторы.
+ xslt позволяет снять часть задачи с php и некоторые вещи генерируются с использованием xslt очень удобно и просто (например локализованные версии сайта).
+xslt никогда не даст тебе оставить не закрытым тег :) и вообще писать html шаблоны с сипользованием xslt — хорошая практика для программистов, по началу возникают проблемы как писали выше мол «иногда для одного HTML тега столько наворотишь.», но с набором опыта проблема решается и учишь верстать красивее и писать более красивые xslt шаблоны, без лишних наворотов.
и он очень изящный, кстати :)
тогда удаляйте с вашего сайта весь ajax и вообще весь JS, потому что он обрабатывается на клиенте.
будете вы писать лишний код, непонятный код или медленный код — это все зависит только от вас, а не от технологии, с помощью которой вы разрабатываете.
кстати, xslt в плане понятности очень хорош — там код простой и наглядный ( у хороших программистов).
в плане скорости xslt тоже не проигрывает при нормальном использовании
будете вы писать лишний код, непонятный код или медленный код — это все зависит только от вас, а не от технологии, с помощью которой вы разрабатываете.
кстати, xslt в плане понятности очень хорош — там код простой и наглядный ( у хороших программистов).
в плане скорости xslt тоже не проигрывает при нормальном использовании
Вы уж определитесь «Код отрабатывающийся на клиенте — Это ПЛОХО» или хорошо. Если плохо — то JS «должен быть удален нахрен».
начнем с того, что xslt это не язык разметки, а язык преобразований xml-документов.
Немного разные вещи, вам не кажется? :) язык разметки это html.
Далее xslt очень хорошо структурирован, и разделяется уж точно лучше чем JS :)
Кроме того, для хорошей технологии не нужны толпы поклонников — достаточно чтобы ее поддерживала хорошая крупная компания (в случае XSLT это W3C).
Да, ее не используют массово. Зато ее используют на многих крупных российских проектах, таких как
— Яндекс
— Мейл.ру (мой круг)
— Студия Артемия лебедева использует XSLT активно и имеет даже собственную платформу для разработки сайтов parser которая использует xslt и на которой создана куча сайтов ( www.parser.ru/powered_by_parser/ ).
в общем если вам реально интересна технология xslt то можно почитать статью «реабилитация xml/xslt)
habrahabr.ru/blogs/about_cms/22018/
И не надо путать функционал JS и XSLT это абсолютно разные области.
Это все равно что сказать что функционал у автомобиля гораздо больше чем у печтаного станка потому что автомобиль может ездить а печатный станок только крутится
Немного разные вещи, вам не кажется? :) язык разметки это html.
Далее xslt очень хорошо структурирован, и разделяется уж точно лучше чем JS :)
Кроме того, для хорошей технологии не нужны толпы поклонников — достаточно чтобы ее поддерживала хорошая крупная компания (в случае XSLT это W3C).
Да, ее не используют массово. Зато ее используют на многих крупных российских проектах, таких как
— Яндекс
— Мейл.ру (мой круг)
— Студия Артемия лебедева использует XSLT активно и имеет даже собственную платформу для разработки сайтов parser которая использует xslt и на которой создана куча сайтов ( www.parser.ru/powered_by_parser/ ).
в общем если вам реально интересна технология xslt то можно почитать статью «реабилитация xml/xslt)
habrahabr.ru/blogs/about_cms/22018/
И не надо путать функционал JS и XSLT это абсолютно разные области.
Это все равно что сказать что функционал у автомобиля гораздо больше чем у печтаного станка потому что автомобиль может ездить а печатный станок только крутится
Хотелось бы оправдаться за фразу «иногда для одного HTML тега столько наворотишь».
Я имел ввиду ситуации, когда, например, тег или атрибуты зависят от параметров, тогда приходится применять xsl:if или xsl:choose, что увеличивает размер кода. В итоге для одного элемента можно получить десяток строчек кода.
В других шаблонизаторах будет также, но в XSLT каждое такое условие или решение — это тег, что увеличивает размер кода и визуально это выглядит довольно громоздко.
Я думаю, для некоторых это отталкивающий фактор.
Я имел ввиду ситуации, когда, например, тег или атрибуты зависят от параметров, тогда приходится применять xsl:if или xsl:choose, что увеличивает размер кода. В итоге для одного элемента можно получить десяток строчек кода.
В других шаблонизаторах будет также, но в XSLT каждое такое условие или решение — это тег, что увеличивает размер кода и визуально это выглядит довольно громоздко.
Я думаю, для некоторых это отталкивающий фактор.
в шаблонах не должно быть условий.
Не могли бы вы пояснить почему?
Условия это прерогатива только бизнес-слоя?
А если мне надо присвоить класс для элемента, в зависимости от входящих данных?
А если мне нужно поменять название класса, мне нужно будет лезть в бизнес-логику где и менять название?
Условия это прерогатива только бизнес-слоя?
А если мне надо присвоить класс для элемента, в зависимости от входящих данных?
А если мне нужно поменять название класса, мне нужно будет лезть в бизнес-логику где и менять название?
это прерогатива програмного слоя. шаблоны — это как бы не язык программирования, а всё ж язык разметки. они должны указывать что как выглядит, а не что когда показывать.
Опять-таки, не буду спорить, это вопрос идеологический. Замечу только, что это расширенный язык разметки. Что и как выглядит решает CSS, а HTML, который мы получаем на выходе из XSLT, отвечает за данные.
Простейший пример — пункт меню текущего раздела выглядит не так, как остальные. Проще прописать условие в шаблоне, а не в программном слое.
Мы с Иваном обсуждаем использование xslt на стороне сервера, там в шаблонах условия есть и от них никуда не деться :)
ну вообще соглашусь что временами xslt смотрится громоздко, но я бы не сказал что очень громоздко, а при наличии редактора с нормальной посдветкой xslt так вообще отлично :)
ну вообще соглашусь что временами xslt смотрится громоздко, но я бы не сказал что очень громоздко, а при наличии редактора с нормальной посдветкой xslt так вообще отлично :)
Смутно припоминаю, но в IE5 в большинстве тегов поддерживались src для указания XML источника данных. За 12 лет, увы ничего из этого не выросло. А со смертью HTML2 все это скоро заглохнет окончательно и бесповоротно. Имхо.
если ты про datasrc, то сгубила его по всей видимости некроссбраузерность
Клиентский XSLT тоже. К тому моменту, когда Mozilla (Safari,Opera) смогли его освоить. MS вообще забила болт на броузеры. К тому же пошла более модная тема — Ajax. В которой хоть и противоестественно, но задача типа include как-то выполняется
ну да… какая бы замечательная технология не была — без поддержки она ничего не стоит.
А разве IE не был первым браузером, который стал поддерживать <?xml-stylesheet… ?>? По крайней мере, когда я это делал в IE5.5, другие браузеры мне такую возможность не предлагали. И, разумеется, XSLT был доступен через работу с MSXML черех JS. С его же, кстати, помощью делались из JS клиентские запросы, которые спустя много лет назвали ajax'ом.
Я об этом и написал выше. IE5 был самым революционным броузером. Но развитие на этом закончилось. Тот же XSLT1 (!) в IE8 имеет те же баги, что были в прошлом веке у IE5.
ты про какие баги?
Из того что нужно мне — не работает раскрытие комментариев и CDATA.
а что за раскрытие комментов? о0
В IE вроде нормально… а вот FF CDATA не держит (стандартным образом)…
Попробуй в FF перенести содержимое some-tag в выходной XHTML.
Это возможно во ВСЕХ браузерах, КРОМЕ Firefox.
<some-tag>
<![CDATA[
<a href="http://www.visitask.com">
Project management resources
</a>
]]>
</some-tag>Это возможно во ВСЕХ браузерах, КРОМЕ Firefox.
А смысл без FF?
А какой смысл в CSS, если (как утверждает небольшая, но очень громкая группа пользователей) IE их не поддерживает?
Опять же, ситуация, когда какой-то модный браузер не поддерживает некоторый стандарт — не повод прогнуться под обстоятельства и наступить на горло собственной песне.
Опять же, ситуация, когда какой-то модный браузер не поддерживает некоторый стандарт — не повод прогнуться под обстоятельства и наступить на горло собственной песне.
> какой-то модный браузер не поддерживает некоторый стандарт
> — не повод прогнуться под обстоятельства
> и наступить на горло собственной песне.
Я отношусь к этому двояко.
С одной стороны, я считал, считаю и буду считать, что IE наступил на горло собственной песне, выпустив дурацкий IE6, лучше всех совместимый в 2001 году со стандартами CSS W3C. Вместо этого нужно было делать свой стандарт, и ждать пока W3C под него ляжет.
С другой считаю что юзер важнее всех стандартов и модных тенденций. Сайт должен работать по-любому. Но если кому-то очень хочется — он может сделать свой личный персональный сайт так как ему вздумается — на XSLT, на FullAjax, CSS3 и HTML5.
Свои персональные сайты, некоммерческие сайты я делал до сих пор на клиентском XSLT. Нормально работают. Никто не жаловался (кроме юзеров оперы <8.5)
> — не повод прогнуться под обстоятельства
> и наступить на горло собственной песне.
Я отношусь к этому двояко.
С одной стороны, я считал, считаю и буду считать, что IE наступил на горло собственной песне, выпустив дурацкий IE6, лучше всех совместимый в 2001 году со стандартами CSS W3C. Вместо этого нужно было делать свой стандарт, и ждать пока W3C под него ляжет.
С другой считаю что юзер важнее всех стандартов и модных тенденций. Сайт должен работать по-любому. Но если кому-то очень хочется — он может сделать свой личный персональный сайт так как ему вздумается — на XSLT, на FullAjax, CSS3 и HTML5.
Свои персональные сайты, некоммерческие сайты я делал до сих пор на клиентском XSLT. Нормально работают. Никто не жаловался (кроме юзеров оперы <8.5)
>С другой считаю что юзер важнее всех стандартов и модных тенденций. Сайт должен работать по-любому.
>С другой считаю что юзер важнее всех стандартов и модных тенденций. Сайт должен работать по-любому.
>Свои персональные сайты, некоммерческие сайты я делал до сих пор на клиентском XSLT.
Юзеры глючного FF получат хаки на javascript/XSLT и небольшое сообщение о лучах ненависти к FF.
>Нормально работают.
Я написал на клиентском XSLT что-то вроде bbs'ки. И был очень неприятно удивлён, когда увидел в комментариях вместо форматированного текста HTML кишки (в FF).
>Свои персональные сайты, некоммерческие сайты я делал до сих пор на клиентском XSLT.
Юзеры глючного FF получат хаки на javascript/XSLT и небольшое сообщение о лучах ненависти к FF.
>Нормально работают.
Я написал на клиентском XSLT что-то вроде bbs'ки. И был очень неприятно удивлён, когда увидел в комментариях вместо форматированного текста HTML кишки (в FF).
значит ты что-то сделал не так
>значит ты что-то сделал не так
Конечно. Моя ошибка была в том, что мой XSLT код соответствовал W3C стандартам, а не кривому но модному браузеру.
Ответа на вопрос, как в детище корпорации Мозилла вывести в документ содержимое CDATA секции или преформатированного текста, я от Вас так и не получил. Собственно говоря, Ваш ответ мне и не нужен. Есть стандарт и в нём описано какой XSLT код должен решать такую задачу.
Конечно. Моя ошибка была в том, что мой XSLT код соответствовал W3C стандартам, а не кривому но модному браузеру.
Ответа на вопрос, как в детище корпорации Мозилла вывести в документ содержимое CDATA секции или преформатированного текста, я от Вас так и не получил. Собственно говоря, Ваш ответ мне и не нужен. Есть стандарт и в нём описано какой XSLT код должен решать такую задачу.
Не знаю как насчёт IE… не видел там с XSLT багов.
А вот Mozilla уже 8 лет кладёт х** на разработчиков и стандарты, отказываясь поддерживать стандарт XSLT из-за того, что не хотят бросать чужой кривой модуль. Причём это не какой-нибудь баг IEшной разметки… фуррифокс работает так, что не починить никак.
К сожалению, за последние годы эта рыжая зараза расползлась так широко, что о каком нормлальном data-driven XML/XSLT на клиенте можно забыть, как об умершей мечте.
А вот Mozilla уже 8 лет кладёт х** на разработчиков и стандарты, отказываясь поддерживать стандарт XSLT из-за того, что не хотят бросать чужой кривой модуль. Причём это не какой-нибудь баг IEшной разметки… фуррифокс работает так, что не починить никак.
К сожалению, за последние годы эта рыжая зараза расползлась так широко, что о каком нормлальном data-driven XML/XSLT на клиенте можно забыть, как об умершей мечте.
Даже если все было бы в шоколаде и все броузеры дружно бы поддержали XSLT2 вряд ли бы что получилось. Нужна поддержка со стороны поисковых машин. В чистом виде XML+XSLT непригоден. Нужны доп. преобразования на стороне сервера. В результате особого облегчения не получается.
ты о чём? о0"
Читаем https://bugzilla.mozilla.org/show_bug.cgi?id=98168 и наслаждаемся безуспешными попытками веб девелоперов в течение 9 лет заставить корпорацию Мозилла следовать стандартам W3C.
Ну или механически повотряем за чьим-то голосом в голове: «это не баг, это фича».
Ну или механически повотряем за чьим-то голосом в голове: «это не баг, это фича».
у каждого своё видение как делать правильно. сделав так они здорово повысили перфоманс, ибо не происходит промежуточного преобразования в текст. одно дерево напрямую преобразуется в другое.
это, конечно, неприятно, но не смертельно.
это, конечно, неприятно, но не смертельно.
>у каждого своё видение как делать правильно
Поэтому и существуют стандарты, которые объясняют как правильно, не позволяя всяким «видениям» нарушить совместимость.
>они здорово повысили перфоманс, ибо не происходит промежуточного преобразования в текст
Ага. Ещё Firefox здорово повышает перфоманс, не проигрывая видео в формате h264 (оно здорово процессор жрёт). А IE6 повышает перфоманс за счёт отказа от рендеринга SVG и полупрозрачных PNG.
А вообще, если думать собственной головой, а не принимать на веру всякий FUD, то легко понять, что без таких преобразований можно обойтись в 99.9% случаев (и в любом случае, это на порядок быстрее существующих workaround'ов). Надо только освободить свой разум и немного пораскинуть мозгами. Дерзайте! =)
Поэтому и существуют стандарты, которые объясняют как правильно, не позволяя всяким «видениям» нарушить совместимость.
>они здорово повысили перфоманс, ибо не происходит промежуточного преобразования в текст
Ага. Ещё Firefox здорово повышает перфоманс, не проигрывая видео в формате h264 (оно здорово процессор жрёт). А IE6 повышает перфоманс за счёт отказа от рендеринга SVG и полупрозрачных PNG.
А вообще, если думать собственной головой, а не принимать на веру всякий FUD, то легко понять, что без таких преобразований можно обойтись в 99.9% случаев (и в любом случае, это на порядок быстрее существующих workaround'ов). Надо только освободить свой разум и немного пораскинуть мозгами. Дерзайте! =)
А как это сказывается на памяти, скорости рендеринга и вообще тормознутости работы интерфейса не проверял пока? Потому как очень заманчивая штука, но паранойяяяяя : D
неа, для этого нужно какой-нибудь реальный сайт на это дело перевести и посмотреть… а у меня таких нет ._."
Можете посмотреть примеры и оценить:
complexml.org/ (http://habrahabr.ru/blogs/php/76570/)
erum.ru
x9.ru
complexml.org/ (http://habrahabr.ru/blogs/php/76570/)
erum.ru
x9.ru
Вот если бы Firefox поддерживал стандарт XSLT, вместо того, чтобы пиариться проприетарной реализацией черновиков «стандарта» HTML5…
Ну да, мечты, мечты…
Ну да, мечты, мечты…
ну не поддерживает он некоторый специфических фич хслт — не такая уж сильная беда.
Вы в теме вообще?
Представьте, что IE не поддерживал бы CSS. Вообще никак, никакими хаками. Где был бы сейчас веб?
P.S. Да, люди бы научились писать Javascript скрипты, которые читают CSS файлы, парсят их, проходят по всему DOMу и программно расставляют стили для всех элементов. Ощущаете глубину геморроя? Корпорация Mozilla для XSLT девелоперов как раз такое будущее и приготовила.
Представьте, что IE не поддерживал бы CSS. Вообще никак, никакими хаками. Где был бы сейчас веб?
P.S. Да, люди бы научились писать Javascript скрипты, которые читают CSS файлы, парсят их, проходят по всему DOMу и программно расставляют стили для всех элементов. Ощущаете глубину геморроя? Корпорация Mozilla для XSLT девелоперов как раз такое будущее и приготовила.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Кроссбраузерные HTML инклуды \(^_^)/