Holden Nov 10 2010 at 16:19

Решение проблем обработки XSLT на стороне клиента (часть 2)

5 min

8.3K

Comments 11

remal Nov 10 2010 at 17:26

Знаете, я с XSLT давно работаю и что-то никак не придумываются примеры где бы disable-output-escaping был нужен. Те что вы привели, там не нужен совершенно.

GrossHo Nov 10 2010 at 23:30

А как же баннерная реклама? Она вся держится на исключениях и не-XML-like коде.

GrossHo Nov 10 2010 at 23:33

И, кстати, нередко у менеджеров, что набирают сайт, кроме кривых рук еще имеют полное отсутствие мозгов. Если менеджер дополнен еще болезнью острой необучаемости (тупизм), то disable-output-escaping=«yes» — единственный выход.

remal Nov 10 2010 at 23:35

Зачем? Если у вас сайт много работает с XML, то использование тулов аля tidy как бы подразумевается…

GrossHo Nov 11 2010 at 09:48

tidy — да. Чтобы менеджеры не порвали сайт своей версткой приходится использовать. А во фремах бывает удобней оставить «орфографию автара», иначе они потом возникают — почему текст свой не узнать. javascript блоки опять же без disable-output-escaping выглядят неествественно.

remal Nov 11 2010 at 13:06

Js — да. Но их можно запихать в комментарии через <xsl:comment/>.

Holden Nov 12 2010 at 00:10

хорошо, скажите тогда как бы вы реализовали вывод результатов поиска с выделенным искомым словом.

remal Nov 12 2010 at 00:23

А что, <some-xml-tag>текст с искомым словом и продолжением после этого слова</some-xml-tag> — не валидный XML? На подобное не натравить XSLT?

Holden Nov 12 2010 at 01:04

<item><![CDATA[Резельтат поиска не валидный]]></item>
<item><![CDATA[Резельтат поиска или даже валидный]]></item>

данные в узлах xml не должны изменять структуру xml-документа, поэтому если данные содержат теги, то они обрамляются в <![CDATA[… ]]>

remal Nov 12 2010 at 06:02

Ну изменят, ну и что дальше? Мир — не идеален! Чем плодить хаки, проще сделать более гибкий XML. Всегда где-то приходится идти на компромисс.

Holden Nov 12 2010 at 11:16

При чём здесь хак к валидному xml?

Show the best of all time