Как стать автором
Обновить

Комментарии 76

Читал вашу книгу, где-то месяц назад.
Понравилось, как раз то, что надо для того, чтобы начать работать с XSLT.
спасибо! это и было основной целью — помочь начать.
НЛО прилетело и опубликовало эту надпись здесь
интересно, сейчас почитаем. жалко, что не нашел эту статью раньше.
НЛО прилетело и опубликовало эту надпись здесь
На xmlhack только часть книжки выложена. А так книжка очень хорошая но кому то может показаться слишком «толстой»
самого главного по этой ссылке нет:

3. Идея и модель языка XSLT
4. Структура преобразования
5. Шаблонные правила
6. XPath-выражения
7. Основные элементы XSLT

Переводи, с кармой попробуем разобраться :)
Для начинающих именно с UMI хорошо только есть недочеты:
например:

<xsl:template match=«udata[@mode='content'][@method = 'menu']»>
<ul>
<xsl:apply-templates select=«items/item» />
</ul>
</xsl:template>

в случае если на странице нету меню нарисует пустой ul

так же нет ни одного примера рекурсии — что весьма полезно.

а так поздравляю.
Там в конце на стр. 69-70 есть один пример с рекурсией.
Рекурсия без выхода или без кол-ва проходов… брррр )))
жажда контроля?
да просто пару раз север положил из ошибки в рекурсии вот и все ))) отсюда эта жажда )))
udata[@mode='content'][@method = 'menu'] довольно странная конструкция, первый раз вижу чтоб так писали. По-моему так udata[@mode='content' and @method = 'menu'] и нагляднее и правильнее (или там не «and» а «or» нужно?
Нормальная конструкция. Предикаты выполняются последовательно, поэтому сначала выберется множество элементов udata, потом из них выберутся все с указанным атрибутом mode, а потом из оставшихся отфильтруются по значению атрибута method. В случае, когда пишем предикат в одних скобках, он будет целиком применяться к каждому элементу множества, полученого на предыдущем шаге. Понятно, что в данном случае принципиального значения не имеет, как писать, но в некоторых случаях может получиться выигрыш (когда простой предикат способен существенно уменьшить мощность множества).
Прикольно. Спасибо, не знал. Хотя думаю тут какие-то XSLT процессоры могут и соптимизировать конструкцию самостоятельно, но полагаться на это не стоит.
Это интересно, есть примеры где бывает выигрш?
По принципу отложенных вычислений в логическом выражении «И» вторая проверка не выполняется, если в первом получен отрицательный результат. Лишних действий поидее выполняться не должно?
я бы поправил: это шаблон для обработки результатов макроса — следовательно, на той странице, на которой нет меню и незачем этот макрос вызывать.
у вас по такой же аналогии идет выбор новостей из ленты. Так лента новостей может быть, а новостей в нет нет ))) опять будет пустой элемент. Просто надо охватывающий элемент вешать на items а уже из него вызывать item ))
все верно насчет элемента, я не спорю.

однако и ситуация, когда лента есть, а новостей в ней нет, тоже не вполне здоровая :)
а можно вообще в месте вызова макроса прописать условие, и все будет ок:

<xsl:apply-templates select=«document(...)/udata[items/item]»>
Про рекурсию писал здесь
habrahabr.ru/blogs/xslt/47545/

До продолжения руки так и не дошли :(
Собственно, в результате успеха этой статьи и появился блог XSLT.
Потом только дошли руки попросить народ перенести в блог свои статьи.
Ну и если новые вижу, то тоже добавляю кармы и прошу в сюда в блог перенести.
Ну у вас то правильная рекурсия с выходом )))
ух ты www.umi-cms.ru/.xml

(кстати, странно что у вас содержимое страницы из wysiwyg вставляется в XML-ку в виде заэскейпенного html кода… так понимаю выводится с disable-output-escaping Думаю логичнее было бы в виде нормального xml вставлять а потом выводить простым копирующим шаблоном..)
Проблема в том, что wysiwyg-поле редактируется пользователем, который чаще всего понятия не имеет о том, что такое well-formed XML. Для надежности мы его «заворачиваем» в CDATA.
Однако, для продвинутых пользователей есть настройка в CMS, после включения которой содержимое поля wysiwyg пытается преобразоваться в XML, который можно не только выводить с помощью copy-of, но и обрабатывать как угодно.
В принципе с помощью Tidy это обычно лечится. Но я вас понимаю — он не на всех хостингах может быть включен, ну и раз это опционально то «прощаю» )
парсим хтмл с помощью DOMDocument и им же сериализуем в XML. у меня даже санитайзер на xpath запросах к этому прикручен. так чт не вижу причин не отдавать пользовательский хтмл в виде нормального дерева, которое можно дополнительно зашаблонить.
Тоха — где эта кнопка?
В config.ini есть настройка в секции [core]. Выстави ее в «1»

property-value-mode=«1»
Имхо, это какая-то неправильная кнопка.
Для неопытного юзера необходимо минимизировать возможность вляпаться в ошибки и заодно при помощи tidy принудительно вычистить всякую ерунду типа MS Word из HTML. А вот для опытного пользователя, да еще и имещего доступ у исходникам можно дать возможность самостоятельно под себя играть с HTML и чистить его по своим правилам.
В процитированной вами статье Кэя про это сказано:
«Не используйте disable-output-escaping. Некоторые люди используют эту магическую приправу, но не понимают, что она делает. Они надеются, что это может заставить код работать лучше. Этот атрибут только для профессионалов, и профессионалы используют это только как последнее средство спасения. В 95% случаях, если вы встретили в преобразовании disable-output-escaping, это говорит о том, что автор был новичком, не понимающим, что он делает»
UMI вообще странная система. Мне очень понравилась сама идеология пользовательского интерфейса, которую вы заложили. Но реализовано это (в той части что меня интересовала) уж больно страшно. Хотя бывает и хуже :)
Хочу попросить Вас высказаться поподробнее по поводу интерфейса — что именно понравилось и что именно страшно. Мы готовим 3е поколение системы с новыми интерфейсами, нам нужны отзывы по существу.

Буду очень признателен за отзыв, в личку или в публичку — на Ваш выбор.
Меня очень напрягли две вещи:
1. очень тяжелый бэкофис.
2. достаточно сложный интерфейс. Вряд ли юзабилитисты там работали. Хотя для системы такого уровня как UMI, наверное имело смысл пригласить.
Я год назад сравнивал по этим параметрам разные движки здесь: erum.ru/article/33
Еще раз спасибо за статью «Реабилитация» и за «Другую книгу» тоже. Хотя последняя не ах :)
За год очень многое изменилось, админка полностью переработана, скрипты переписаны, prototype+scriptaculous больше не используются, так что ваш обзор немножко устарел :)
В интернете все быстро устаревает. Кроме мифов об XSLT.
А новую UMI обязательно посмотрю. Может еще что полезного найду для себя.
По поводу disable-output-escaping спорить не буду, но tidy думаю стоит подключить опционально.
$xhtml= DOMDocument::loadHTML('broken html' )->saveXML()
молодцы, разжевали хорошо %-)
не хотите попробовать XStyle? это набор кротких и удобных макросов для основных конструкций xslt www.php.ru/forum/viewtopic.php?p=230747
он пока ещё не полностью дописан, но если заинтересует — допилю.
мой велосипед прямее, быстрее, надёжнее и интероперабельнее В-)
хмл вы просто так выводите? не камильфо.
мы подключали клиентское xslt преобразование, для вывода красивого дерева с фолдингом, гиперссылками на связанных хмл-ки и прочими плюшками.
>клиентское xslt преобразование

Как сейчас с ним дела обстоят? Помню когда пробовал xslt поддерживало его более-менее нормально 1,5 браузера и те чуть ли не с дев-веток. Можно ли сейчас использовать выдачу xml c xslt на стороне клиента для выдачи основного контента на продакшене?
>Помню когда пробовал xslt поддерживало
Последним из броузеров не поддерживающих XSLT была Опера ~ 8.5
Как раз когда я пробовал XSLT он и вышел…

Хм, а почему тогда до сих пор клиентские преобразования так не популярны?
Большая часть php-программистов до сих пор бодается что лучше — Smarty или голый php, вы удивляетесь почему клиентское преобразование не пошло.
Не знаю почему. Наверное слишком много мифов выросло вокруг этой темы. И в основном в среде php-разработчиков. Те кто работает с Java и .NET как-то более продвинуты.
Конечно, голый php :D Но это вопрос как формировать выходной xml и, может быть, сам xslt. Какое отношение это имеет к клиентскому преобразованию и причём тут php не понимаю :-/
>Какое отношение это имеет к клиентскому преобразованию
Самое прямое. О клиентском XSLT говорят только те, у кого нет никаких проблем с внедрением серверного. Или точнее те, кому серверного становится мало.
К примеру, если есть проблемы с валидностью в HTML, как у UMI, о клиентском преобразовании надо забыть — броузеры не понимают disable-output-escaping.

>и причём тут php не понимаю
php-программисты _в_массе_своей (я не говорю о всех, но о массе) менее квалифицированные чем прочие, поэтому у них и возникают проблемы с переходом на XSLT, и при этом их в России на порядок больше чем всех прочих, поэтому они и задают тон в болталках типа хабра
>Самое прямое. О клиентском XSLT говорят только те, у кого нет никаких проблем с внедрением серверного. Или точнее те, кому серверного становится мало.

Спорно, я вот первым делом пробовал внедрить его на клиентах, но столкнувшись с проблемами внедрил на сервере (в php4 приложении и не только в качестве шаблонизатора, но и в качестве (x)html-парсера), а потом и вовсе отказался от использования.

Правильно. Сначала нужно внедрить на сервере, а уже потом на клиенте :)

Зачем создавать лишнюю нагрузку на сервер, клиентов много, а он один, пускай клиенты «думают» :)
Хотя бы для того, чтобы боты адекватно индексировали сайт.
Хорошо или плохо, но XSLT пока никто из них выполнять не может.
Это кстати одна из видимых причин почему клиентское преобразование не пошло. Я кстати не знаю, предусмотрено ли в UMI,HostsCMS и т.п. цепочки преобразований или только одна финальная обработка большого XML.
хорошая и интересная мысль. насколько я знаю, в планах такое когда-то было, так что может быть будет потом сделано.

а нельзя где-нибудь ваш пример посмотреть, красивый с фолдингом и прочими плюшаками?
попробую поискать исходники, но наврятли найду
А почему бы не использовать более удобные вещи, например www.twig-project.org/ в качестве шаблонизатора?
Это было бы проще и удобнее…

То есть чем именно XSLT лучше если лучше? Оно больше гикам должно нравиться, мне кажется (ну, то есть тем, кто вместо простой и понятной даже новичку Ubuntu ставит какую-нибудь Gentoo, имея при этом какие-то сомнительные преимущества и кучу сложностей и так далее)…

А для шаблонизатора довольно популярной cms ИМО не лучший выбор… Ведь он должен быть простым, удобным и понятным рядовому верстальщику… Кроме того, важна скорость разработки, чтобы не особо долго копаясь во всём это быстро сделать сайт иначе cms не соответствует интересам разработчика…

То есть вопрос не ради холивара, а просто чтобы понять, чем обоснован такой гиковский выбор в негиковской цмске?

Когда-то давно вроде бы в UMI был Smarty или мне кажется?

Вот если сравнить по скорости разработки сайта — сколько надо времени для создания шаблонов на twig, smarty и XSLT-шаблонизаторе?

P.S. К слову вопрос: обожаю шаблонизатор, который в Django ну и Jinja2, из пхпшных на них только twig похож?
В ЮМИ помимо xslt есть простой в освоении tpl-шаблонизатор.
Так что можно выбирать: попроще, но покондовее или посложнее, но более гибкий.
ясно, да так удобнее… от XSLT верстальщик точно будет не в восторге…
от «простой в освоении tpl-шаблонизатор» тоже, но не сразу
НЛО прилетело и опубликовало эту надпись здесь
xslt банально быстрее.
У меня в плане книг все проще:


Beginning XSLT 2.0: From Novice to Professional


XSLT 2.0 and XPath 2.0 Programmer's Reference
Прочитав последнюю главу (часть про «вредные» инструкции) понял почему XSLT лет 5 назад мне не понравился. Вернее идея понравилась, мало того я сам нечто подобное «изобрёл» до того как узнал про XSLT, но вот то что у меня получалось на практике — соверешенно неподдерживаемые кучи call-templates, if, choose, for-each с километровыми XPath на один apply-templates — очень не нравилось.

Спасибо, приятно узнать, что подвела не интуиция, а кривые руки — их выпрямить проще :)
Имхо интуиция вас подвела. Так же как и автора книги.
«Все действительное разумно, все разумное действительно» (с) Гегель.

Меня она подвела в том, что разрабатывать на декларативном языке я начал с императивным подходом (другого тогда просто не знал), неосознанно пытаясь реализовать на XSLT аналоги PHP/Smarty шаблонов.
«4. Template rules and xsl:apply-templates are not an advanced feature to be used only by advanced users. They are the most basic fundamental construct in the XSLT language. Don't keep putting off the day when you start to use them. If you aren't using them, you are making your life unnecessarily difficult»

разработчика Saxon XSLT (Michael Kay) тоже интуиция подводит?
Вы превратно поняли слова гуру.
В приведенном вами тексте я не увидел здесь ни одного слова о безусловном запрете xsl:if, xsl:choose, xsl:for, xsl:value. Но я хорошо помню, в книге М.Кэя«XSLT: руководство программиста» в конце девятой главы «Образцы проектирования таблицы стилей», говорилось, что в реальная практика далека от шаблонов мышления пуристов.
«Все действительное разумно, все разумное действительно» (с) Гегель.
xsl:value? xsl:for? запрете? :)) если речь была про <xsl:value-of>, то странно видеть ее в ряду с xsl:if и xsl:choose

xsl:for вы вообще только что выдумали :)))

речь вообще не шла о запрете. тем более безусловном. ни тут, ни в книге. речь шла именно о подходе.
а слова «most basic fundamental» трудно понять как-то неоднозначно.
> xsl:for
xsl:for-each. Вы успокоились?
> Вы еще не включили в список вредных инструкций xsl:value
Вы еще не доросли до крайней степени xslt-пуризма. Поэтому объясню. xsl:value в ваших примерах выводит то же самое что и xsl:apply-templates, но в случае если элемент по-ходу мзменится (например наченет содержать дочерние элементы) вам придется вносить дополнительную правку в том месте где вы вляпали xsl:value
Это то о чем вы талдычите, не понимая смысла «most basic fundamental»
вы зря обижаетесь. то, что я не понял вашего «сокращенного» синтаксиса, говорит лишь о том, что это было неочевидно для меня и все.

что касается вывода значений при помощи xsl:apply-templates — то она их выводит, если шаблон не найден и используется встроенный шаблон:

xsl:template match=«text()|@*»
xsl:value-of select="."/>
/xsl:template

в котором мы видим xsl:value-of. впрочем, я думаю, вы это и так прекрасно знаете.

однако мысль про такую крайнюю степерь пуризма вполне понятна. и ваш пример вполне резонный, тут есть над чем подумать, спасибо.
НЛО прилетело и опубликовало эту надпись здесь
disable-output-escaping — вынужденная мера. можете почитать комментарии выше.
и про "//" тоже есть замечание. это лишь указание, с предупреждением.

однако, ни то ни другое — не относятся к идеологическим проблемам, хотя да, согласен, понятие «зло» можно оценивать по-разному. просто опыт показывает, что зачастую проблемы именно идеологические (см. первый комментарий в этой ветке).

НЛО прилетело и опубликовало эту надпись здесь
кстати, как насчёт внедрения клиентских трансформаций и железного кэширования, как описано тут? habrahabr.ru/blogs/client_side_optimization/90481/ если нужна помощь или консультация — у меня сейчас есть время
отличный, кстати, вышел бы диплом)
А можно как-нибудь получить книжечку? ссылка больше не работает
Зарегистрируйтесь на Хабре, чтобы оставить комментарий

Публикации