Почему стоит выбрать XSL-преобразование?

Question

Почему стоит выбрать XSL-преобразование?

Как говорили другие, вы не можете надежно обнаружить недопустимый указатель. Рассмотрим некоторые формы, которые может принять недопустимый указатель:

У вас может быть нулевой указатель. Это то, о чем вы могли бы легко проверить и что-то сделать.

У вас может быть указатель где-то за пределами допустимой памяти. То, что составляет действительную память, зависит от того, как среда выполнения вашей системы устанавливает адресное пространство. В системах Unix обычно это виртуальное адресное пространство, начинающееся с 0 и идущее на некоторое количество мегабайт. На встроенных системах это может быть довольно мало. В любом случае он может начинаться не с 0. Если ваше приложение работает в режиме супервизора или эквивалент, ваш указатель может ссылаться на реальный адрес, который может быть или не быть резервным с реальной памятью.

У вас может быть указатель где-то внутри вашу действительную память, даже внутри вашего сегмента данных, bss, стек или кучу, но не указывая на действительный объект. Вариант этого - указатель, который указывал на действительный объект, прежде чем что-то случилось с объектом. Плохие вещи в этом контексте включают освобождение памяти, повреждение памяти или повреждение указателя.

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

Проблема становится еще хуже, если вы рассматриваете архитектуры на основе сегментов / смещений и другие реализации нечетных указателей. Такие вещи, как правило, скрыты от разработчика хорошими компиляторами и разумным использованием типов, но если вы хотите пробить завесу и попытаться перехитрить операционную систему и разработчиков компилятора, ну, вы можете, но нет единого способа для этого, который будет обрабатывать все проблемы, с которыми вы могли бы столкнуться.

Лучшее, что вы можете сделать, это разрешить крах и выпустить хорошую диагностическую информацию.

23

template-engine java xslt

задан B.E. 6 May 2009 в 12:03

16 ответов

Другие вопросы по тегам:

template-engine java xslt

Похожие вопросы:

score 1 · Answer 1

В отличие от HTML, есть доступно множество инструментов XML, если вам нужно каким-либо образом анализировать и обрабатывать шаблоны. Поэтому вы должны выбрать XML, чтобы получить преимущества от использования инструментов и библиотек для XML.

Тем не менее, может быть, XHTML может соответствовать вашим потребностям, так как это дает вам полную поддержку инструментов и библиотек XML, оставаясь при этом нормальным. HTML, который корректно обрабатывается современными веб-браузерами. Если вам потребуется выполнить их последующую обработку, вы все равно можете применить XSLT к данным XHTML.

score 5 · Answer 2

Путь XSL обеспечит безопасность вашего приложения в будущем. Это означает, что если вы в будущем решите добавить больше шаблонов с различными макетами, вы сможете воспользоваться этими преимуществами. В моем текущем проекте мы сохраняем используемый XML (в XMLType или CLOB) и позволяем другим приложениям получать доступ к данным и шаблонам XSL для генерации документов через веб-сервис. Это была запоздалая мысль об оригинальном дизайне, который было очень легко реализовать из-за нашего решения использовать XML / XSL.

score 2 · Answer 3

Я вижу, как подход XSL может быть полезен, если ваши данные уже являются XML.
Но обычно это не так. Он находится где-то в базе данных, должен быть сгенерирован на месте или получен из какого-либо сервиса.
Создание XML из этого источника, чтобы потом иметь возможность создавать HTML из этого XML, на мой взгляд, бесполезно. Я бы придерживался (X) HTML-шаблонов.

score 4 · Answer 4

When we have done XSLT in the past, it was to allow the ability to extend our product. The output remained the same, only the presentation layer needed to change. This allowed us a lot of flexibility when we had clients that wanted to "customize" their UI, since all we needed to do was replace the XSLT file. If you foresee needing to make a lot of those kinds of changes, XSLT might be your answer.

However, as stated above, the XSLT syntax and functional programming mentality can make it difficult to effectively produce templates. We found that we liked to stick to the tricks that we learned and when we had client requests that fell outside of what we already knew, no one wanted to volunteer for the ticket. Usually someone eventually figured out how to do the task and our "bag of tricks" got larger, but it was often very cumbersome to figure out new things.

If you don't foresee change the UI ever, or at least not much, XSLT may not be worth the extra effort.

score 2 · Answer 5

Я думаю, вам нужно проверить, каким будет источник ваших данных. Как уже упоминал ранее Борис Калленс, если вы извлекаете данные из базы данных, вам придется сначала преобразовать в XML, а затем применить свои преобразования. Если источником данных является RSS или что-то подобное, то естественным выбором будет XSLT.

XPATH и XSLT имеют высокую кривую обучения, и функциональное программирование может быть сложным, чтобы обнять вас. Со временем это может быть неправильным выбором.

Для работы на переднем конце JSON имеет меньшую полезную нагрузку и легко поддерживается jQuery и другими библиотеками Javascript. Возможно, вы захотите рассматривать JSON в качестве протокола данных, поскольку библиотека jQuery гораздо более доступна для разработчиков, а время для продуктивности с каркасом намного меньше, чем с XSLT, встроенным Javascript в теги,

score 4 · Answer 6

Преимущество XSLT в том, что он позволяет также выводить данные в других типах документов (например, в формате pdf), и вывод в формате PDF очень вероятен в настоящее время. XML / XSLT также отделяет данные от представления.

score 2 · Answer 7

В зависимости от вашего приложения наличие слоя XML, который затем преобразуется в XHTML через XSLT, также означает, что вы можете легко создавать веб-сервисы на уровне XML - что позволяет вашим клиентам использовать данные ваших сайтов. ..

Отправка XML в браузер со ссылкой на преобразование (забыл точный синтаксис ...) также означает меньшую пропускную способность, так как файл XSLT останется прежним, и вам нужно только передать необработанный XML построен из - вроде как использование внешней таблицы стилей CSS вместо добавления атрибутов стиля в вашу разметку;)

score 1 · Answer 8

Я использовал XML и XSLT в предыдущем проекте, на финансовых веб-сайтах, и это сработало для нас, но:

У нас было несколько клиентов, которые меняли количество выходов, которые у нас были. Мы могли бы заменить таблицу стилей XSLT и это внесло изменения в сайт проще управлять для разработчиков
В нашей команде был специализированный веб-редактор. Мы дали им пример XML, и они могли редактировать таблицы стилей напрямую
. Если вчера на веб-сайте требовалось внести какие-либо изменения в формулировку (это был банк, это происходило на удивление часто), мы могли бы просто развернуть новый XSLT без повторное развертывание всего сайта.
Требовалось несколько различных форматов вывода. Мы использовали FOP для преобразования в PDF, который основан на той же технологии, поэтому нам было несложно понять: -)

Основная причина, по которой я вижу использование XSLT, заключается в том, что у вас есть несколько сайтов, основанных на одном и том же XML, но требующих разного вывода HTML.

score 19 · Answer 9

Я создал XML / XSLT- управляемый пользовательский интерфейс для корпоративного продукта около 5 лет назад. Мы все еще используем его, и теперь я могу оглянуться на свой опыт и увидеть много плюсов и минусов:

Плюсы:

XSL - мощный декларативный язык, полезный и интересный для опытных разработчиков, а преобразования могут делать довольно удивительные вещи в нескольких строках кода
XSL разработан для использования с XML, поэтому, если ваши данные уже являются XML, тогда это имеет большой смысл
Разделение задач (рендеринг vs. data) лучше, чем многие языки шаблонов
Визуализация на основе XSL может быть легко разделена на подклассы. Под этим я подразумеваю: допустим, у вас есть класс данных A со связанным шаблоном A.xslt. Для класса B, производного от A, вы можете легко создать B.xslt с небольшими различиями и включить A.xslt для унаследованного поведения. Это снижает вероятность взлома из-за изменений в A.xslt.
Вышеупомянутый пункт также дает вам возможность выполнять переопределения. Для класса A со связанным A.xslt мы можем легко переключить связанный шаблон на A-custom.xslt, что представляет собой несколько небольших изменений плюс наследование A.xslt. Мы можем сделать это «на лету» в полевых условиях, и, опять же, преимущество состоит в том, что A-custom.xslt представляет собой всего несколько строк, а не полностью измененную копию исходного A.xslt. Небольшой размер означает, что он с большей вероятностью будет работать с несколькими версиями A. xslt.
В .NET 2.0 XSLT компилируется и становится очень быстрым. Для Java может быть аналогичная технология. (Большинство языков шаблонов делают это и сейчас.)
В .NET можно создать «Object XPath Navigator», который позволяет вам преобразовывать ваши объекты данных без необходимости их преобразования в объект XML. Опять же, в Java может быть похожая технология
XSLT хорошо разбирается в HTML и обрабатывает экранирование, проблемы с пробелами и т. Д. Хорошо

Минусы:

XSL - мощный декларативный язык, сбивающий с толку начинающих программистов и меньшее количество людей хорошо знаю XSLT
XSL многословен. XML тоже часто многословен.
Преобразования XSL, вероятно, медленнее, чем «родные» шаблоны. Даже после компиляции в XSL все еще больше накладных расходов на состояние, чем в большинстве языков шаблонов
. Трудно передавать параметры в XSL, вы должны либо отправлять их в соответствии с вашими данными (вынуждая вас создавать дополнительный XML), либо с помощью системных методов (которые также могут включать построение данных XML)
Если у вас нет ObjectXPathNavigator или его эквивалента, вы вызовет значительные накладные расходы при преобразовании ваших объектов данных в XML для преобразования
В зависимости от возможностей вашего преобразователя вы также можете понести накладные расходы на буферизацию при преобразовании в строковый буфер и последующей отправке этой строки на устройство вывода
чем выше вы используете XSLT, тем меньше вероятность того, что ваши инструменты поддержат вас (особенно, когда вы начнете использовать include или более быстрые способы передачи XML-данных)

Я постараюсь обновить, поскольку у меня появятся новые проблемы. Я думаю, что сейчас, оглядываясь назад, я вынесу вердикт: придерживаться общего языка шаблонов. То, что когда-то было большими проблемами, когда я выбрал XML / XSLT, теперь решено новыми и более зрелыми версиями основных движков шаблонов. Мы по-прежнему получаем большие преимущества от возможности наследования файлов .xslt, с чем большинство движков шаблонов не справляется. Но, в конце концов, ценность наличия большого количества разработчиков, предоставляющих примеры, намного выше (сравните, например, ответы ASP.NET и ответы XSLT на StackOverflow.)

Надеюсь, что это поможет!

score 21 · Answer 10

XSLT is a functional programming language and you can use it to create frontends as rich as any templating system. However, you shouldn't — you and your team will go insane.

Both options present the opportunity of transforming objects into a presentation form in a logical sort of way. XSLT is best suited for creating more XML, which might lead you to believe that it's a perfect candidate to use to create XHTML. However, creating XHTML shouldn't be the primary goal — Creating a user experience is. Don't concern yourself with the medium.

Two significant drawbacks to XSLT concern the syntax: Your templates, and the templates that they include, and the templates that those templates include will all be gigantic and verbose. Second, you'll have to do a lot of functional programming, and less-experienced engineers may be confused and terrified when they encounter a recursive template with an accumulating function parameter instead of a simple for loop.

If you're attracted by the beauty of transforming logically-constructed, valid XML entities, consider instead a type-safe templating system that transforms beans instead. Check out Google XML Pages, and create logically-organized, type-safe templates that will be easy for future engineers to pick up and extend.

score 2 · Answer 11

http://fishbowl.pastiche.org / 2002/02/12 / xslt_is_the_spawn_of_satan /

2

ответ дан 29 November 2019 в 00:42

score 2 · Answer 12

Будь проще. Это принцип, который ценится все больше и больше.

Velocity или Freemarker невероятно гибкие и универсальные. Ваша кодовая база будет четкой, легко понятной и будет работать намного (намного) быстрее, чем чудовища X.

score 4 · Answer 13

Пожалуйста, не используйте XML / XSLT для веб-интерфейсов. Я участвовал в подобных проектах, и это ужасно. Часто вам нужно сначала создать XML из объектов или чего-то подобного, что не имеет смысла. Во-вторых, существует так много хороших бесплатных редакторов HTML, но я не нашел ни одного для XSLT. Так что редактировать сложный XSLT - неинтересно. Я бы порекомендовал использовать HTML-шаблоны и обычный шаблонизатор.

score 18 · Answer 14

Я думаю Ubuntu Muslim Edition использует этот тип функций в календаре, возможно, вы могли бы поискать там

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

Поддержка инструментов, как правило, очень хороша ... если у вас есть бюджет. XMLSpy и Stylus Studio были для меня очень полезными в прошлом.

XSLT не только сложен, но, что более важно, отличается. Большинство людей не являются выпускниками компьютерных наук, получив формальную подготовку по функциональному программированию. Большинство программистов напишут XSLT в процедурном стиле, который не будет использовать возможности языка и доставит вам головную боль при обслуживании.

Преобразования XSLT могут быть медленными и занимать много памяти. У вас могут возникнуть проблемы, если у вас есть таблица стилей с большим вводом XML.

Мне нравится XSLT, но стоит ли вам его использовать или нет, сводится к нескольким пунктам:

Вы привержены XSLT? У вас есть серьезный внутренний опыт работы с XSLT? Готовы ли вы их получить?

Являются ли ваши данные в XML? Имеет ли смысл в XML? Есть ли у вас кто-то в компании, кто любит ваши данные настолько, чтобы убедиться, что они хорошо структурированы и всегда есть подходящая схема?

Если ответ на эти вопросы - да, и у вас есть сложные данные, требующие сложного процесса визуализации, я бы не стал Не рассматриваю использование XSLT ... особенно, если в команде нет опыта. Плохой XSLT намного, намного хуже, чем плохой шаблон.