Pull to refresh

Comments 18

Вообще-то все это делает стандартными средствами XSLT — www.w3schools.com/xsl/el_output.asp

Поэтому при надобности вывода в HTML, можно просто пропустить документ через маленький шаблончик.
Дело в том, что иногда (очень часто) нужно использовать один и тот же шаблон для генерации и XHTML и HTML. Более того, XSLT в .Net не умеет правильно сериализовывать в HTML при установки метода вывода в html. Там есть труднообходимые особенности. И, конечно же, это уже не будет HTML5.
Ну так наложите для генерации HTML один маленький шаблончик, задачей которого будет только преобразование XML -> HTML.

Что значит «XSLT в .Net не умеет»? Есть разные парсеры. Тот же самый Saxon есть и для Java, и для .Net. С ним у меня проблем сериалайза в HTML не было.

Может, вы просто плохой парсер используете? Ну так это не повод плодить извращения.

Если же у вас проблемы с Saxon'ом, то будет интересно послушать, т.к. я с ним сам работаю.
А я не хочу saxon. Есть стандартный xslt из .net, который отлично справляется. А небольшие неровности его работы вполне себе исправляются. Но, в любом случае, спасибо. Ценю ваше высказанное мнение.
Стандартный XSLT в .Net — это устаревшее убожество. В свое время пришлось использовать AltovaXML через COM-обертку чтобы получить вменяемый XSLT в своем приложении. А ведь еще поддержку XQuery обещали… э-эх.
Да, к сожалению, XQuery еще в 2-м фреймворке обещали но потом убрали… жаль.
Но, я бы не стал .Net xslt-процессор так называть — нужно провести реальные замеры производительности чтобы как-то сравнивать.
Правильно, зачем использовать лучший XSLT процессор, когда можно написать кучу костылей?..

В той же Java Saxon умеет эмулировать стандартные интерфейсы XSLT преобразований, поэтому его внедрение происходит очень быстро и просто. Думаю и в .Net тоже самое.
Какой процессор лучше — это предмет для обсуждения, который данной статьей не поднимался, поэтому и здесь я бы не хотел это обсуждать. У меня есть свое мнение на счет Saxon, которое я также здесь не хочу говорить.
Суть в том, что здесь представлено решение конкретной задачи — использование XmlWriter для форматирования в соответствии с правилами HTML. Что его можно использовать для XSL-трансформаций — это вопрос другой.

Кстати, и все-таки, разве в Saxon можно использовать один и тот же шаблон для генерации XHTML и HTML, без использования хаков в XSLT?
Назовите любой другой XSLT процессор, поддерживающий хотя бы сравнимый набор функциональностей. Достаточно хотя бы того, что процессоров, поддерживающих XSLT 2.0, можно пересчитать по пальцам одной руки

Во-первых, в XSLT 2.0 есть тег <xsl:result-document>.
Во-вторых, ваша задача решается так: генерируется XHTML, потом на него накладывается ЕЩЕ ОДНО XSLT преобразование, которое делает HTML вывод.
То, что можно наложить еще одно преобразование — сомнений нет, но зачем это делать, если можно просто заменить сериализатор.

Вот взять опять же html5, документ которого описывается некой объектной моделью, которая укладывается в xml. Согласно спецификации она может быть сериализована либо в xhtml (по правилам xml) либо в html (по правилам, которые я привел в статье). Следовательно на входе должна быть объектная модель xml (пусть это бедет XmlDocument, XDocument, XPathNavigator или результат трансформаций) а на выходе текстовое представление в одном из форматов. И задача получить правильное представление ни какого-то дополнительного преобразования, а сериализатора.

А то, что вы предлагаете сделать, это дополнительная ненужная работа — это не кошерно =)

Без обид — мы просто, видимо, про разное говорим.
Какая разница как получать HTML строку — сериализатором или еще одним XSLT преобразованием? Только во втором случае мы имеем решение из коробки.

Вам в любом случае надо будет выводить строку. По сути — выводить результат XSLT преобразования. Будут две цепочки действий:
1. Сделали XHTML, вывели как строку
2. Сделали XHTML, преобразовали в HTML, вывели как строку

Зачем что-то заменять и писать велосипеды, когда есть хорошее готовое решение? Я чего-то не понимаю? Может, ваш вариант лучше, надежнее, быстрее для понимания другими разработчиками?

Дополнительная и ненужная работа у вас. Ибо нормальный разработчик, который знает про возможности XSLT, сделал бы все за 5 минут при помощи лишнего XSLT преобразования. Вы же слабо знаете возможности самого XSLT и XSLT процессоров, но, тем не менее, пишите статьи «правильная ...» (если что, я готов признать свою неправоту)

Короче, разговор ни о чем. Покажите, пожалуйста, чем ваше решение лучше мною предложенного на конкретных примерах.

ЗЫ: Я не пишу и никогда не писал на .Net. Так что чем отличается XmlDocument от XDocument не знаю.
Видимо вы опять не про то. Я не пишу про то какое решение лучше или хуже для XSLT. Я пишу о том как XHTML представление сериализовывать по HTML-правилам.
Заметьте, это ваши слова: «при помощи лишнего XSLT преобразования». Зачем нужно делать преобразование вообще? Просто есть другие правила форматирования — это не какая-то другая структура. Я не спорю, что можно сделать это на XSLT, но это просто глупо.

А ваше утверждение про мои знания XSLT и процессоров безосновательны. Я здесь не обсуждаю вопросы самого XSLT. Здесь решение задачи вышестоящего уровня.

Я не буду сомневаться в ваших знаниях XSLT, потому как видно, что это единственное слово, которое вы поняли, и не можете понять что статья не он XSLT.
перенесите плиз в блог .NET, посты из личного блога не попадают на главную Хабра
кармы не хватало, спасибо за подкинутую — перенес.
UFO just landed and posted this here
UFO just landed and posted this here
Неправильно.
script не может содержать ссылок на сущности. Это raw-text элемент.
Правильный HTML-парсер должен не распознавать ссылки на сущности.
Т.е. в данном случае, это будет трактоваться не как текст «google-analytics-config-compiled.js», а как текст "&google-analytics-config;".
Возможно, вы имели в виду:
<script type="text/javascript" src="&google-analytics-config;"></script>
если так, то — да, так можно. Но это атрибут.
Насколько понял из этого объявления сущности, его разбором будет заниматься XML-парсер на входе в XSLT, что совсем не то, о чем я писал. Здесь имеется в виду запись выходного потока XML по правилам HTML.
Sign up to leave a comment.

Articles