Зачем играть! framework выбрал Groovy для механизма шаблонов

Ответ 1

JSP невозможен, поскольку каждый JSP компилируется в Servlet, а API сервлета предоставляет такие вещи, как сеанс на стороне сервера, которые не совместимы с парадигмой RESTful. Мы не хотим возвращаться к темным временам плохо масштабируемых сессий на стороне сервера, проблем с завязкой в ​​браузере, ретрансляции и т.д.

Japid шаблоны интересны, но они не подкреплены большим сообществом и, возможно, даже не существовали в то время, когда была создана игра (я не знаю наверняка, хотя). Я попробовал Japid в качестве замены шаблонов Groovy в моем собственном приложении и обнаружил в тесте JMeter, что преимущество будет только незначительным, от 10% до макс. Улучшение на 25%.

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

Groovy в целом неплохие или медленные. Используйте типизированные переменные везде, где это возможно (вместо "def" ), даже при закрытии! Сохранять значения доступных свойств в локальных переменных. Проведите разумный поиск результатов. Затем скрестите пальцы, чтобы GSP мог работать на groovy ++ в будущем, и вы закончили;)

Для меня вопрос не в том, почему они использовали Groovy в представлениях. То есть, потому что я скорее скучаю по нему в слое контроллера. Groovy сделает кодирование поведения контроллера намного проще ИМХО.

Ответ 2

Во-первых, JSP не был допустимым вариантом для Play, так как он решил не спускаться по маршруту Java EE (какой JSP является частью). Вместо этого Play решил использовать Groovy как интуитивно понятный, простой, но мощный механизм шаблонов.

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

Самым популярным является Japid. Он утверждает, что он на 2-20 раз быстрее, чем стандартный шаблонный движок, и некоторое время был вокруг. Для получения дополнительной информации см. Здесь http://www.playframework.org/modules/japid.

Второй вариант - это Кембридж, хотя это было только ненадолго, но достаточно активно в досках объявлений (см. https://groups.google.com/forum/?hl=en#!searchin/play-framework/cambridge/play-framework/IxSei-9BGq8/X-3pF5tWAKAJ).

Я склонен придерживаться Groovy, поскольку мне нравится, как он работает, и не обнаружил, что это слишком плохо с точки зрения производительности, но каждое приложение индивидуально, поэтому ваши собственные тесты производительности должны приводить вас к собственный путь.

Ответ 3

Да, есть Джапид. Это намного, намного быстрее.

http://www.playframework.org/modules/japid

Ответ 4

Я полностью согласен с выбором легкости по сравнению с тем, что сделали дизайнеры Play Framework. Я предполагаю, что если шаблоны начинают мешать с точки зрения производительности, вы можете (и должны!) Измерять медленные биты и реорганизовывать их в быстрые теги, где это возможно. При этом вы, скорее всего, сэкономите 80% процессора, переместив 20% в быстрые теги, оставив вам гибкость и адекватную скорость.

Сказав это, я с нетерпением жду эксперимента, который я планирую увидеть, насколько хорошо новые шаблоны Scala (слабо "заимствованные" из Razor.NET - отличный чистый синтаксис) работают с контроллерами/моделями Java. Бэкэнд Scala еще не существует с точки зрения сравнительной легкости, но язык шаблонов, безусловно, потрясает.

Ответ 5

Я могу опоздать на вечеринку в 2016 году. Play 2 вышел, и JDK (не говоря уже о аппаратном обеспечении) значительно улучшился. Я не использую Play или Spring Boot, так как моя платформа им не нужна - просто чистый текст в режиме исполнения /HTML из шаблонов.

Во-первых, когда речь идет о шаблонах Groovy, их больше. Я использую оригинальный Groovy SimpleTemplateEngine для чего-либо от электронных писем до богатых веб-страниц, независимо от того, большинство людей в настоящее время предпочитают "расширенный" MarkupTemplateEngine с синтаксисом не-HTML-компоновщика. Я не пошел по этому маршруту из-за поддержки IDE (например, UntelliJ) для JSPish HTML файлов с использованием JavaScript-ловушек закрытых тегов, фигурных скобок и т.д. Кроме того, как бы вы включили JavaScript в шаблон стиля "строитель" в фигурных скобках?

Какой бы вы ни выбрали, как SimpleTemplateEngine, так и MarkupTemplateEngine статически компилируют свои шаблоны, хотя документ Groovy только упоминает его для последнего. Почему бы не создать класс для первого? Я не сравнивал их друг с другом, но я ожидал бы, что SimpleTemplateEngine будет быстрее, поскольку он... ну, проще - не переводит какой-либо синтаксис в конкатенации String с ifs и циклами между ними.

И это действительно очень быстро. Я был обеспокоен вызовом его в цикле. Не имеет значения. Накладных расходов нет, поскольку шаблон компилируется один раз.

Я использую несколько небольших шаблонов, ответственных за создание отдельной разметки управления формой (HTML + JS) для создания составной формы, включенной в контейнер более высокого уровня, включенного в другой контейнер и т.д., пока не будет сформирована вся страница. Разделение вашего взгляда, как вы уже догадались, делает его, как вы уже догадались, модульным, инкапсулированным и "объектно-ориентированным", состоящим из множества отдельных компонентов MVC, построенных друг на друге. Похоже на старые добрые пользовательские JSP-теги, которые оцениваются только во время выполнения и совместимы с такими технологиями, как Spring Boot, если вы не можете противостоять модным возобновляющим вещам вроде этого.

Тестовая форма со 100 полями (все комплексные "умные" элементы управления с инкапсулированным управлением и поведением) отображает в 150 мс первый раз, а затем через 10-14 м. В отладчике IDE на моей голодной памяти 4y.o. блокнот. Я также проверил, что он потокобезопасен, поскольку Groovy никогда не упоминал об этом явно. Почему бы и нет, если он скомпилирован в класс без категории Groovy, как любой другой? Вызовите createTemplate() один раз, сохраните шаблон где-нибудь и используйте его (вызовите Template.make()) в своем сервлете или другом параллельном контексте. Очевидно, у меня никогда не будет формы из 100 полей в реальном приложении. Любой, кто это делает, должен пересмотреть свой UX.

Эффективность вполне адекватна. Я бы даже принял одну секунду, чтобы отобразить 100-страничную страницу. Подумайте об этом, вам не нужны предельные характеристики отслеживания наноразмерных или ядерных ракет в веб-приложении. Если вы это сделаете, выберите Jamon: http://www.jamon.org/Overview.html, который генерирует класс Java, который вы обычно пишете, чтобы объединить строки. Я не тестировал его, так как мне не нравятся дополнительные шаги компиляции (автоматически выполняемые Maven, но все же). Скомпилированный Groovy байт-код для меня достаточно хорош - по сравнению с скомпилированной, да, сильно типизированной Java. Разница была бы маргинальной, если вы не делаете что-то сложное, чего вы не должны внутри шаблона (см. Ниже). Играя с типизированными переменными Groovy vs. def, как было предложено в этом потоке, только сохранила мне пару миллисекунд за этот 100-шаблонный запуск.

Шаблоны не должны иметь много процедурной логики (внутренние переменные, ifs и loop) в любом случае - что контроллер, а не вид ответственности. Тем не менее, ifs и loop являются обязательными для механизма шаблонов. Зачем использовать Handlebars/Mustache, если он может просто вызвать String.replace()?

Остальные двигатели шаблонов также не имеют значения. Никакая конкатенация строк (например, Velocity или Freemarker) или интерпретированная технология JS (например, Jade) никогда не превзойдет самый прямой подход Jamon к производительности. И будучи программистом на Java, вы хотите использовать свой любимый язык/синтаксис: либо напрямую (Jamon), либо на 90% ближе к Java, Groovy (это сценарий с ориентированной на сценарии сжатой интерпретацией Java). Я не стал бы комментировать Scala - вопрос предпочтения. За исключением его якобы "сжатого" синтаксиса (менее и менее значимого с Java 8+) стоит цена. И только для сложных циклов. Вы не хотите писать все приложение внутри одного шаблона, как я уже сказал. Пара циклов и до десяти, если утверждения max.

И, как и все упомянутые, ключом является интуитивный синтаксис и простота использования. Они резко сокращают количество ошибок. Хороший (дополнительный) сервер стоит 1000 долларов, а зарплаты разработчиков - для исправления всех ошибок, возникающих из-за сложности оптимизации предельной производительности, в 100 раз выше.