Обоснование для отдельных файлов шаблонов HTML в веб-приложениях Scala?

Question

Каждый, кто занимался разработкой веб-приложений в Scala, знает, что вы можете использовать любой существующий веб-фреймворк Java или Lift.Общим для всех этих фреймворков является то, что им всем требуется два или более файлов для генерации страницы: некоторый HTML-шаблон и один или несколько классов для обеспечения связанной логики.Даже если вы пишете приложение только для JSP, вы, вероятно, по-прежнему используете множество пользовательских тегов.

И это подводит меня к тому, что я заметил: файлы шаблонов часто мало похожи наHTML.Файлы шаблонов Wicket в значительной степени представляют собой HTML, потому что в Wicket компоненты связываются с тегами HTML в шаблоне.Но во всех средах, основанных на пользовательских тегах, шаблоны обычно полны пользовательских тегов и не могут быть воспроизведены в браузере сами по себе.

Scala поддерживает встраивание произвольного XML непосредственно в исходный код программы.Вот функция Scala, которая создает ненумерованный список из коллекции:

def listify[T](items: Iterable[T], liBody: T => NodeSeq) = <ul>{
  items.flatMap(i => <li>{liBody(i)}</li>)
}</ul>

Теперь, если у меня есть это, я уже отказался от архитектурной чистоты, потому что у меня есть теги ul и li в «контроллере», или«бизнес-логика» или «вспомогательный объект», или как вы его называете, а не в шаблоне.Тем не менее, это довольно четкий и простой способ создания списка.Чтобы сделать это любым другим способом, необходимо заменить некую встроенную инфраструктуру привязки тегов вместо собственных встроенных функций Scala.

Поэтому мне интересно, почему бы просто не пойти другим путем и избавиться от шаблонов?Если Scala полезен для создания ненумерованного списка, то почему он не может создать то, что содержит ненумерованный список?И вплоть до страницы обратно к тегу html.

Я задаю вопрос: учитывая язык, который уже включает мощную поддержку XML, есть существенные преимущества использования файлов шаблонов и их преобразования вфактический HTML во время выполнения, или лучше просто рассматривать файлы шаблонов как артефакты, перенесенные из языков без встроенной поддержки XML, и отказаться от них?

Answer 1

Краткий ответ: оба.

Вам не «нужно» использовать шаблоны даже с Lift - вы можете писать представления прямо в коде. Мало документировано, но возможно.

Однако, если вы попробуете, вы быстро обнаружите, что ваш код представления становится уродливым с проблемами компоновки и стиля. Если вы хотите попробовать, попробуйте скопировать, скажем, главную страницу Facebook в сыром Scala;).

Если над проектом работает более 2-3 человек, естественно, возникает разделение обязанностей. Model-View-Controller популярен не потому, что Интернет является хорошим примером этого (это действительно дурацкий пример), а потому, что это наилучшее приближение такого разделения обязанностей - HTML / CSS / JavaScript являются обычно не люди PHP / Java / Scala, и оба вида должны быть в состоянии быть продуктивными независимо.

Короче говоря, если вы хотите написать свои взгляды в Scala, могу я посоветовать выяснить, как это сделать в Lift - вы получите щедрое количество другой вкусной добычи, потратив время на ее изучение. После того, как вы написали, возможно, приложение или два таким образом, спросите себя, был ли это опыт, который вы хотели бы повторить. :)

Answer 2

Я думаю, что главная причина - поддержка инструментов. Инструментальные средства легче поддерживать, когда частью проекта является исключительно XML (файлы шаблонов). Гораздо сложнее (хотя и не невозможно) манипулировать кодом из инструмента проектирования.

Кроме того, в большинстве производственных сред крайне важно абстрагировать бизнес-логику от «представления» (используя любую понравившуюся вам парадигму, MVC, MVP и т. Любой достаточно большой проект, вероятно, будет слишком громоздким, чтобы обойтись без него. Помните, что в производственных средах часто бывает более одного программиста, и иногда новые программисты присоединяются к команде или уже работают, поэтому это не является обязательным. Большая часть усилий разработчиков веб-фреймворка вложена в этот вариант использования, поэтому функциональность, которая нарушает эту абстракцию, является менее приоритетной.

Однако я мог видеть, где внутренний scala DSL для веб-разработки может быть полезен для небольших проектов. Конечно, было бы неразумно тратить свое время на создание облегченной структуры для такого использования, если вы сочтете это полезным. Скорее всего, если вы создали его и нашли его полезным, другие тоже могут.

Предлагаемые ресурсы:

• Программирование Scala, Глава 10: Стадирование XML в Scala
• Программирование Scala, Глава 11: Специфичные для домена языки в Scala

Answer 3

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

Например, вы можете определить тег-обертку, который берет все узлы внутренней таблицы и добавляет нечетные и четные классы к каждой из строк. (См. this .) Конечно, вы можете сделать это и в своем методе listify (или tabularify), но тогда вы потеряете еще большую чистоту.

Для простых приложений с несколькими контроллерами, я думаю, что можно обойтись без шаблонов, как показано в уже упомянутой step framework . Вы просто говорите «напечатать этот список» и все готово. Однако для более крупных платформ ваша логика становится все более и более сложной. Должен быть способ сообщить приложению, когда и где должен вызываться каждый контроллер. Скорее всего, вы определите это в одном XML-документе - и это снова ваш XML-шаблон, от которого вы хотели избавиться.
И затем, в зависимости от того, кто собирается разрабатывать шаблон, вы либо хотите разрешить код в XML, либо хотите его избежать. А из-за простоты обработки XML в scala вы на самом деле не пропустите ее, если ее избежать, поскольку у вас есть другие способы обойти это.

Теперь шаблоны XML лифта явно не являются скалами, поэтому прямого способа вставки логики скала нет. Другие структуры могли бы выбрать другой маршрут. Кроме того, я думаю, что вы можете просто создать собственный тег XML для своего тела HTML, а затем иметь функцию, в которой вы намеренно смешиваете код scala с материалами XML для получения выходных данных.