Для текущего проекта необходимо принять решение о том, следует ли использовать XML и XSL-преобразование для создания HTML или напрямую использовать HTML-шаблоны.
Мне бы интересны аргументы за или против XSL-подхода. Я понимаю, что в тех случаях, когда вы должны поддерживать множество разных макетов, XSL-решение имеет много преимуществ, но почему вы выбираете его в тех случаях, когда вам нужно только поддерживать один макет назначения?
Изменить: Мы говорим о Java здесь.
XSLT - это функциональный язык программирования, и вы можете использовать его для создания интерфейсов, столь же богатых, как и любая система шаблонов. Однако вы не должны - вы и ваша команда сойдете с ума.
Оба варианта предоставляют возможность преобразования объектов в форму представления в логическом виде. XSLT лучше всего подходит для создания большего количества XML, что может заставить вас поверить, что это идеальный кандидат для создания XHTML. Однако создание XHTML не должно быть основной целью - создание пользовательского интерфейса. Не беспокойтесь о среде.
Два существенных недостатка в XSLT относятся к синтаксису: ваши шаблоны и используемые ими шаблоны, а также шаблоны, которые включают эти шаблоны, будут иметь гигантский и подробный характер. Во-вторых, вам придется выполнять много функционального программирования, а менее опытные инженеры могут быть запутаны и запуганы, когда сталкиваются с рекурсивным шаблоном с параметром функции накапливания вместо простого цикла.
Если вас привлекает красота преобразования логически построенных, правильных XML-сущностей, вместо этого следует использовать систему шаблонов, защищающую тип, которая преобразует beans. Проверьте Google XML-страницы и создайте логически организованные шаблоны, безопасные для будущих инженеров, которые будут собираться и расширяться.
Я создал пользовательский интерфейс, основанный на XML/XSLT, для корпоративного продукта около 5 лет назад. Мы все еще используем его, и теперь я могу оглянуться на свой опыт и увидеть множество плюсов и минусов:
Плюсы:
Минусы:
Я попытаюсь обновить, поскольку я думаю о большем количестве проблем. Я думаю, что оглядываясь назад, мой вердикт будет придерживаться общего языка шаблонов. Когда-то большие проблемы, когда я выбрал XML/XSLT, были рассмотрены более новыми и более зрелыми версиями основных движков шаблонов. Мы по-прежнему очень выигрываем от способности наследовать файлы .xslt, что является чем-то большим, чем у большинства движков шаблонов. Но в конечном итоге ценность наличия множества разработчиков, предоставляющих примеры, намного больше (сравните ответы ASP.NET и ответы XSLT на StackOverflow, например.)
Надеюсь, что это поможет!
Я сделал значительное развитие с использованием XSLT, и он был чрезвычайно успешным и полным сбоем на двух разных сайтах.
Несколько мыслей перед заключением:
Я не думаю, что кто-то будет утверждать, что XSLT намного мощнее, чем механизм анализа синтаксиса, это функциональный язык.
Несмотря на то, что он не так широко принят как большинство процедурных языков, он по-прежнему является реальным языком, который используется там для реальных проектов, людей можно нанять уже со знанием XSLT, и это передаваемый навык для вашего нынешнего персонала.
XSLT также существует уже некоторое время, реализация зрелая, я уверен, что это относится к долго работающим шаблонам (например, Velocity), но более новые версии могут быть менее надежными.
Какой бы язык шаблонов вы не определили, он вряд ли будет документирован как XSLT. Просмотрите любую из справочных серий Michael Kay Programmer для примера о том, как сделать отличный справочник.
Поддержка инструментов, как правило, очень хороша... если у вас есть бюджет. XMLSpy и Stylus Studio были очень полезны для меня в прошлом.
XSLT не только тяжелый, но, что более важно, другой. Большинство людей не являются выпускниками компьютерных наук, которые официально прошли обучение по функциональному программированию. Большинство программистов будут писать XSLT в процедурном стиле, который не будет использовать какую-либо силу языка и не даст вам головной боли обслуживания.
Преобразования XSLT могут быть медленными и могут занимать много памяти. У вас могут быть проблемы, если у вас есть таблица стилей с большим XML-вводом.
Мне нравится XSLT, но нужно ли его использовать или нет, сводится к нескольким моментам:
Вы привержены XSLT? У вас есть серьезный собственный опыт в XSLT? Готовы ли вы получить некоторые из них?
Являются ли ваши данные в XML? Это имеет смысл в XML? У вас есть кто-то, кто любит ваши данные, чтобы убедиться, что он хорошо структурирован, и всегда есть соответствующая схема?
Если ответ на эти вопросы да, и у вас есть сложные данные, требующие сложного процесса рендеринга, я бы не стал использовать XSLT... особенно если в команде нет опыта. Плохой XSLT намного, намного, намного хуже, чем плохой шаблон.
Однако он может отображать сложные данные в поддерживаемом виде, что было бы невозможно с использованием многих современных шаблонов.
Переход по пути XSL будет в будущем доказательством вашего приложения. Если вы решите в будущем добавить больше шаблонов с разными макетами, вы сможете воспользоваться этими преимуществами. В моем текущем проекте мы сохраняем используемый XML (в XMLType или CLOB) и позволяем другим приложениям получать доступ к данным и шаблонам XSL для создания документов через веб-службу. Это была мысль о первоначальном дизайне, который был очень прост в реализации из-за нашего решения использовать XML/XSL.
Пожалуйста, не используйте XML/XSLT для веб-интерфейсов. Я был в таких проектах, и это ужасно. Часто вам нужно сначала создать XML из объектов или что-то подобное, что не имеет смысла. Второй момент заключается в том, что есть так много хороших редакторов HTML там бесплатно, но я не нашел их для XSLT. Поэтому редактирование сложного XSLT не забавно. Я бы рекомендовал пойти с шаблонами HTML и общим механизмом шаблонов.
Преимущество XSLT заключается в том, что он может также выпускать выходные данные в других типах документов (например, pdf), и в настоящее время выход pdf очень вероятен. XML/XSLT также отделяет данные от представления.
Когда мы уже делали XSLT в прошлом, это позволяло расширять наш продукт. Выходные данные остались прежними, и только слой презентации должен был измениться. Это позволило нам проявить большую гибкость, когда у нас были клиенты, которые хотели "настроить" свой пользовательский интерфейс, поскольку все, что нам нужно было сделать, это заменить файл XSLT. Если вы предвидите необходимость внесения таких изменений, XSLT может быть вашим ответом.
Однако, как указано выше, синтаксис XSLT и менталитет функционального программирования могут затруднить эффективное создание шаблонов. Мы обнаружили, что нам нравилось придерживаться трюков, которые мы узнали, и когда у нас были запросы клиентов, которые выпадали за пределы того, что мы уже знали, никто не хотел добровольно участвовать в билете. Обычно кто-то в конечном итоге выяснил, как выполнить задачу, и наш "пакет трюков" стал больше, но часто было очень громоздко выяснять новые вещи.
Если вы не предвидите изменение пользовательского интерфейса когда-либо или, по крайней мере, не так много, XSLT может не стоить дополнительных усилий.
Я вижу, как подход XSL может быть полезен, если ваши данные уже являются XML.
Но обычно это не так. Он где-то в базе данных должен быть сгенерирован на месте или происходит с некоторой службы.
Создание XML из этого источника, чтобы иметь возможность создавать HTML из этого XML, бесполезно, на мой взгляд. Я бы придерживался шаблонов (X) Html.
В зависимости от вашего приложения, имеющего XML-уровень, который затем преобразуется в XHTML через XSLT, также можно использовать, чтобы вы могли легко писать WebServices на уровне XML, что позволяло вашим клиентам использовать данные ваших сайтов...
Если XML, отправленный в браузер с ссылкой на преобразование (забыл точный синтаксис...), также меньше требуется для полосы пропускания, поскольку файл XSLT останется прежним, и вам нужно только передать необработанный XML, который он построен из - вроде как использование внешней таблицы стилей CSS вместо добавления атрибутов стиля к вашей разметке;)
Думаю, вам нужно выяснить, каков будет источник ваших данных. Как уже упоминалось ранее, boris callens, если вы вытаскиваете из базы данных, вам придется сначала преобразовать XML, а затем применить свои преобразования. Если источником данных является RSS или тому подобное, то XSLT является естественным выбором.
XPATH и XSLT имеют высокую кривую обучения, а функциональное программирование может быть сложным, чтобы обнять руки. Во время кризиса это может быть неправильным выбором.
Для работы на передней панели JSON имеет более легкую полезную нагрузку и легко поддерживается jQuery и другими библиотеками Javascript. Возможно, вы захотите рассмотреть JSON как протокол данных, поскольку библиотека jQuery намного более доступна для разработчиков, а время для производительности с помощью структуры намного меньше, чем с XSLT, встроенным Javascript в тегах, ужасным синтаксисом и всеми остальными мелочами, которые поставляются с XML/XPATH/XSLT на передней панели.
Держите его простым. Это тот принцип, что каждый получает возможность ценить все больше и больше.
Velocity или Freemarker невероятно гибкие и универсальные. Ваша база кода будет понятной и понятной, и она будет работать намного быстрее, чем X-чудовища.
http://fishbowl.pastiche.org/2002/02/12/xslt_is_the_spawn_of_satan/
В отличие от HTML, существует множество доступных инструментов XML, если вам нужно каким-либо образом обрабатывать и обрабатывать шаблоны. Поэтому вы должны выбрать XML, чтобы получить преимущества использования инструментов и библиотек для XML.
Однако, возможно, именно XHTML соответствует вашим потребностям, поскольку это дает вам полную поддержку XML-инструментов и библиотек, в то же время являясь обычным HTML, который правильно обрабатывается современными веб-браузерами. Если вам нужно выполнить последующую обработку этих данных позже, вы все равно можете применить XSLT к данным XHTML.
Я использовал XML и XSLT в предыдущем проекте, финансовые веб-сайты, и это сработало для нас, но:
Основная причина, по которой я вижу использование XSLT, заключается в том, что у вас есть несколько сайтов на основе одного и того же XML-документа, но требующих разного вывода HTML.
XML + XSLT действительно классный. У вас есть возможность выводить многие типы целевых форматов в будущем. Но я не знаю встроенный HTML в XML. Firefox XSLT не поддерживает "disable-output-escaping". См. Bugzilla.
Мы используем XSLT для генерации html в нашей системе управления контентом, и он отлично работает.
Некоторые подсказки: не пытайтесь сгенерировать всю страницу сразу из одного большого волосатого XML, вы сойдете с ума. Используйте HTML-шаблон (обычный текст /html файл со стилями, украшениями и базовой разметкой) со встроенными маркерами (например, <! - MENU → , <! - CONTENT → ) и замените маркеры с xslt-преобразованием соответствующих данных.
Сказав это, я сомневаюсь, что вам действительно нужен xslt, если вы только собираетесь иметь один макет, навсегда.