Pull to refresh

Comments 18

Вы уж меня простите, но что не так с производительностью Play? Подняли несколько энтерпрайз проектов на нем. JEE вспоминаем как страшный сон.
Это вы про Play 1.2.x или про Play 2.x? Если про последний, то он страшный сон и есть.
Пользуемся 1.2. Но, насколько я знаю, в 2.х проблемы только со скоростью компиляции во время разработки и это, со слов разработчиков, исправимая трабла, над которой они работают.
Да, и отказываться от него в пользу 2.0 не собираемся.
Верно. В 2.0 много всего накрутили. В итоге почти монстр как J2EE стал. А если сидеть на ветке 1.2 то под нее плагины уже практически не поддерживаются, что печально
Не скажу что все заброшено. Неподдерживаемые плагины это на совести самих авторов. Есть активно развивающиеся плагины.
Вот нарыл свой старый бенчмерк двухгодичной давности, чтобы не быть голословным

habrahabr.ru/post/111464/#comment_3556366

я правда не помню точную версию (посладняя на момент написания статьи).

Про 2.x ничего пока не скажу, надо попробовать

Ах, я понял о чем вы. Вы замеряли скорость работы дефолтного шаблонизатора. Он действительно медленный, т.к. использует груви, есть варианты гораздо быстрее. Тот же Japid или Rythm сравнимы по скорости с выдачей статики.
а что не так с j2ee, точнее с чем именно?
например мы используем ejb3.1 бины, кластеризуются, находятся в пуле, на методах висят interceptors и тд… очень удобно и быстро.
конечно ни о каких orm(jpa) речь не идет, для прототипирования штука может и нормальная, в продакшне на сложных запросах и связях превращается в тормоз по сравнению с нативным jdbc,
по этому связка ejb + нативные запросы это хорошо.
Прототипирование — это вы верное слово нашли. Табак похоже именно для этого.
Насчет JPA — просто не хотел себя ограничивать в будущем, проект создавался чисто из эгоистических целей — чтобы сэкономить мне время настройки на старте, а иногда хочеться и без JPA, иногда и без SQL

Я ничего не имею против JEE — что вас заставило думать обратное?
а что такого с jspx, что вы его жуёте? :) там настолько мало отличий с jsp, что вообще странно, что это вас так возбудило
Ну как минимум больше текста в коде, что усугубляет и без того многословный JSP. Но это еще терпимо. Второе, что меня напрягает немного больше — то что вы не можете просто так взять и написать пустой тег — надо обязательно не забыть <jsp:text /> внутри, — тоже следствие формата XML.

Другая проблема и более важная для меня проблема — подсветка синтаксиса в особо тяжелых случаях смешивания JSPX и JavaScript, — то есть когда она наиболее нужна, даже хваленая IDEA не справляется, и спецсимволы XML, которые просто снижают читаемость вокруг себя до нуля.

В принципе формат хороший, но для своих специфических целей, которые видать Roo и налагает, а обычный синтаксис лично мне более удобен и предсказуем.
больше текста там только в заголовке выходит.
имхо наоборот с подсветкой синтаксиса у jspx лучше, да и смешивать его со скриптом нет никакой нужды :) котлеты отдельно.
внутри пустого тега лучше ставить html-comment, конечно, надо об этом помнить.

к плюсам формата могу еще отнести автоматическое вырезание всех whitespaces в итоговой странице
Ну вырезать whitespace и в обычном JSP можно — как вы и сказали, там все то же самое. Отличная, кстати, штука

<%@ page contentType="text/html;charset=UTF-8" language="java" trimDirectiveWhitespaces="true" %>


Посмотрите в сторону серверсайд-шаблонизатора Thymeleaf.
Майндмап для бытрого ознакомления: www.mindmeister.com/233359419
Использовал его в нескольких пруф-оф-консепт проектах, разрабатывать удобно, и, главное, быстро.
Спасибо, уже используем, правда для почтовых шаблонов :) За майндмапу отдельное мерси
Кстати, кому надо, в свое время создавал для себя spring maven archetype для того, чтобы забутстрапить как раз 3х уровневую модель. По-моему получилось ничего, правда руки не доходят заапгрейдить версии пока, но если что, patch is welcome :)

code.google.com/p/spring-archetypes/
Sign up to leave a comment.

Articles