Почему данные передаются через механизмы шаблонов, такие как Velocity/Freemarker/Thymeleaf

#freemarker #velocity #dataweave

Вопрос:

Я вижу широкое распространение Dataweave, которое, по моему мнению, больше похоже на библиотеку преобразований, такую же, как Freemarker или Velocity. В случае изменения DW в логике преобразования потребуется изменение кода, в первую очередь стали популярны те же механизмы шаблонов, которые используются для разделения логики и кода, чтобы мы могли изменять логику преобразования без необходимости перестраивать/переупаковывать наш код (больше хлопот с развертыванием).

Может ли кто-нибудь помочь мне указать несколько причин, по которым можно было бы предпочесть DW .

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

1. Просто для уточнения, вам не нужно иметь код DW в приложениях. В некоторых случаях имеет смысл выполнить динамическую загрузку DW из базы данных, другого API или даже получить сценарий DW как часть запроса API.

2. Могу я спросить, где вы видите усыновление за пределами экосистемы Mulesoft?

Ответ №1:

TLDR: Если вы ищете механизм шаблонов для таких вещей, как статические веб-сайты, DataWeave определенно не является правильным выбором. Используйте правильный инструмент для этой работы. Кроме того, хотя вы можете использовать DataWeave за пределами Mule, я не думаю, что видел, чтобы кто-то принимал DataWeave, который не принимал MuleSoft..


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

Эти механизмы шаблонов, как правило, предназначены для вывода статического текста. Если вы используете его для вывода структурированных данных, а не для чего-то вроде HTML-страницы.. вы, наверное, делаете это неправильно. Они не собираются возвращать структурированные данные — они собираются возвращать текст. Если вы находитесь в самом конце своего потока и собираетесь вывести это обратно из API или в файл, я полагаю, вы в порядке. но если вы действительно хотите работать с этим выводом, вам придется преобразовать обычный текст в реальный объект… вводя множество дополнительных шагов в этот процесс, когда вы могли бы просто использовать DataWeave в первую очередь. Dataweave особенно полезен, когда вы хотите заниматься такими вещами, как потоковая передача, потому что вы обрабатываете большие полезные нагрузки. Dataweave может понимать JSON, XML и CSV (три наиболее распространенных типа данных, которые я вижу) в потоковом формате без какой-либо дополнительной работы, что очень упрощает создание эффективных приложений. Большая разница между шаблоном и языком преобразования данных заключается в том, что один предназначен для вывода текста с использованием структурированных данных в качестве входных данных, а другой-для работы со структурированными данными при вводе и выводе структурированных данных, с которыми вы можете продолжать работать. Есть причина, по которой почти все документы движка шаблонов говорят о создании веб-сайтов, а не о таких вещах, как интеграция.

Механизм DataWeave, как указал Алед, встроен в среду выполнения Mule. Глубоко так. По умолчанию вы можете использовать DataWeave в любом поле любого соединителя, даже в полях, в которых нет f(x) кнопки, потому что она встроена в среду выполнения. Это делает DataWeave тем, что вы могли бы считать первоклассным гражданином в Mule, в отличие от того, что вы сможете использовать только через соединители или путем вызова java-мостов/библиотек.. что вы делаете с помощью DataWeave или длинной серии операций с соединителями.

Перечисленные вами преимущества также не являются вещами, которые вы не можете сделать с помощью DataWeave. Вы можете ОЧЕНЬ легко шаблонизировать и экстернализировать DataWeave — например, у меня в репозитории maven есть несколько библиотек DataWeave, которые я могу включить в качестве зависимостей. Я создал несколько служб преобразования, которые используют базы данных с DataWeave для выполнения преобразований, что позволяет мне изменять эти преобразования без изменения приложения. Вы также можете использовать dynamic DataWeave, где вы используете систему шаблонов для загрузки определенных частей сценария перед его запуском. Я даже сделал еще один шаг вперед и написал универсальный скрипт DataWeave, который я могу использовать для выполнения базовых сопоставлений без написания DataWeave — это позволило мне довольно легко обернуть веб-интерфейс вокруг вещей.

Я бы не стал использовать DataWeave за пределами MuleSoft, если только вы не являетесь магазином MuleSoft. Если вы являетесь магазином MuleSoft, использование интерфейса командной строки для запуска ваших сценариев, так же, как и для большинства интерпретируемых языков, работает довольно хорошо, тем более что у вас, вероятно, уже есть собственный опыт работы с DataWeave. Язык все еще достаточно нишевый, поэтому, если вы еще не приняли его для использования в приложениях для мула, я не вижу никаких преимуществ в его использовании.

Документы / основные примеры:

https://github.com/mulesoft-labs/data-weave-native

https://docs.mulesoft.com/mule-runtime/4.3/parse-template-reference

https://docs.mulesoft.com/mule-runtime/4.3/dataweave-create-module

https://github.com/mikeacjones/transform-system-api

Ответ №2:

Потому что это язык выражений и преобразований, встроенный в среду выполнения Mule. Если вы используете Mule, он также интегрирован с IDE Anypoint Studio.

За пределами приложений для мула я не думаю, что вы можете легко использовать DataWeave. Возможно, вы захотите пойти с альтернативами.

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

1. Согласен, но я могу использовать эти шаблоны внутри Mule в качестве замены Dataweave и выполнять свои преобразования без необходимости повторного развертывания приложения. Какую дополнительную выгоду предлагает DW

2. Интеграция с IDE дает вам графический дизайнер и предварительный просмотр. Интеграция со средой выполнения означает, что каждое выражение в Mule 4 является выражением DataWeave. И вам не нужно добавлять библиотеки или код для вызова внешней библиотеки. Я думаю, что в этом и заключаются преимущества DataWeave. Вы должны решить, что лучше подходит для ваших конкретных потребностей, которые могут отличаться от других.

3. @darshankamat дело в том, что … вы НЕ МОЖЕТЕ использовать их изначально внутри mule в качестве замены dataweave. Вам пришлось бы использовать какой-то мост, что значительно усложнило бы работу с приложением. В долгосрочной перспективе гораздо проще и удобнее использовать dataweave в приложениях MuleSoft.

4. Я предполагаю, что вопрос был чисто связан с преобразованием, а не заменой основного языка выражения.

5. Это верно, но такой инструмент, как Freemarker, на самом деле является механизмом текстовых шаблонов. Он не предназначен для вывода таких вещей, как структурированные данные, что и должен делать язык преобразования. Кроме того, в Mule вам все равно придется обработать этот текст в структурированный объект.. в приложении для мула угадайте, что это будет делать? Таким образом, вы добавляете много дополнительных шагов … тем более, что, насколько мне известно, у MuleSoft нет официальных разъемов ни для одного из них. Повторюсь… эти движки хороши для вывода таких вещей, как статический текст, например HTML … не структурированные данные, с которыми вы собираетесь работать.