По следам поста «Быстрая разработка веб-приложений на Java»

[Mecid]

Неплохое решение, но для Java разработчиков есть очень удобный playframework, который является новым шагом в мире Java framework'ов, думаю он заслуживает внимание.

[Mecid]

речь идет о быстрой разработки веб приложений на Джава, и это единственный фреймворк который позволит это делать.

[EaE]

Ни одного, ни малейшего, даже в названиях, отличия от Spring MVC. Причем еще старой версии, 2.х, которой в обед сто лет. При этом фреймворк свежий, а значит плохо отлаженный и с минимальной базой пользовательского опыта работы с ним (и решения его проблем) в Сети. Быстро на нем только заглавную страничку налабать можно будет, а после первой же проблемы начнутся… проблемы.

[Mecid]

с чего вы взяли?

[EaE]

С чего я взял что? Что нет отличий? Полистал фреймворк. Он типовой, каких десятки — в веб-разработке сейчас новое слово довольно сложно сказать. Что начнутся проблемы? Это аксиома, я на самом деле не хочу говорить об этом. Что эти проблемы сложнее будет решать? Решение любой нетиповой (не разобранной в туториале) проблемы сейчас находится одним из двух способов: 1) в книжке "… in Action" издательства O'Reilly, которой нет; и 2) в Сети, и тогда количество решенных проблем (и скорость нахождения решения) напрямую зависят от возраста фреймворка. Которым данный экземпляр похвастаться тоже не может.

Детально: в основе у нас что? MVC, классы контроллеров. На морде у нас что? Темплейтный движок «мы не жсп». К базе мы как? По javax.persistance, как все. Валидируемся мы как? Аннотациями JSR-303, причем клиентскую валидацию мы не умеем (как все, однако для того же спринга способ прикрутить клиентскую валидацию по тем же JSR-303 есть — потому что возраст системы способствует; а для этого фреймворка?).

Я не говорю, что фреймворк плохой. Я просто говорю, что он такой же. Как все. Со своими проблемами, которые он специально затачивался, чтобы решать, и со своими уникальными проблемами, которых нет у кого-то еще. Как обычно.

[Mecid]

Разработка на нем ведется в разы быстрее чем на спринге.
Он взял все самое лучшее из рельсов. А ваши проблемы в любом фреймворке есть.

[EaE]

> Разработка на нем ведется в разы быстрее чем на спринге.
Ну вот как, как она там может вестись быстрее, если в нем точно такие же: а) ORM-слой, б) бизнес-логика, в) темплейты вьюх? В чем разница, может, я упустил что-то?

> А ваши проблемы в любом фреймворке есть.
Ну так я об этом и говорю.

[Mecid]

Вы не видели кажется этот фреймворк в действии.
Да он использует почти все тоже самое, но обертки которые там сделаны, увеличивают простоту кода и скорость разработки. Ну и тем самым облегчает жизнь разработчику.

[EaE]

Вы какими-то очень общими фразами говорите. «Обертки, которые там», «увеличивают простоту и скорость», «разработка в разы быстрее», «лучшее из рельсов» (этим только ленивый кстати не кичится нынче). Я же изучил референс по этому фреймворку, и никакой магии там не обнаружил, все точно такое же, более того: я могу при необходимости глава-в-главу сопоставить, со ссылками, референсы по spring и по play. Но я действительно на практике с ним не работал, и пытаюсь понять, стоит ли овчинка изучения. И вполне допускаю, что вижу среди всего массива данных об этом фреймворке только знакомое, оттого у меня такое, возможно неверное, впечатление о нем. Так давайте говорить предметно, какие конкретные фичи улучшают производительность программиста в play? Какие-то может быть утилити классы, или инструменты, или архитектурные решения вы конкретные можете назвать?

[Mecid]

как минимум там есть crud для классов моделей.

[EaE]

www.springsource.org/roo/guide

[Mecid]

ушел со спринга до того, как это появилось. Это что генератор кода чтоли?

[EaE]

Угум. Ну, в том числе. Это та самая «умная» составляющая из рельсов, которая пытается облегчить рутину. Но Roo уже несколько лет, если вы пользовались Spring старых версий, до ну хотя бы 2.5, то я могу понять причину наших разногласий. :)

[Mecid]

последняя версия с которой я работал была 2.5, но 3.0 я смотрел и ничего кроме аннотаций не видел. Но я все такие о фреймворке, а не о генераторе. Такой генератор можно для всего сделать, но если смотреть чисто на фреймворк.

[EaE]

… ииии да. Согласен.

[philpirj]

А если проект Ant + Ivy + IDEA, добиться запуска прямо из IDE не получается из за сотен внешних зависимостей?

[Akvel]

На счет Ivy, не знаю не пробовал

Но использую вариант с Maven — все зависимости нормально подтягиваются из репозитариев и проект запускается под wtp.

[asolntsev]

Конечно получается. Есть плагин IvyIDEA, который умеет подкачивать все зависимости и добавлять в classpath проекта.

[theos]

>я использую WTF

Точно WTF? Или все-таки WTP? :)

[FractalizeR]

WTF лучше :)

[Akvel]

Упс :-) Исправился!

[vip_delete]

>Все обновления подхватываются на лету

Это чисто маркетинговый ход. В любом фреймворке с таким механизмом есть заранее оговоренные ограничения и точно не все обновления подхватываются на лету.

[webus]

+1 за PlayFramework. Особенно хорош в связке со Scala

[Throwable]

На Scala есть знаменитый Lift. Впринципе, разрабатывать еще быстрее, чем на Play, если ты разработчик этого самого Lift )) Для новичков же настолько неудобоварим, что заморачиваться даже не стоит. Как впрочем и практически любая либа на scala, пестрящая закорючками и DSL-ями.

[Akvel]

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

[MikeMirzayanov]

Я не до конца понял: вот добавил я модельный класс, DAO, какой-нибудь сервис, контроллер и шаблон — после этого я смогу в браузере нажать F5 и все заработает без какого-либо редеплоймента? Браузер отобразит новую страницу за секунду или менее?

[norguhtar]

Будет redeployment. Изменения на лету подхватываются только в jsp. Все что лежит в классах требует редеплоймента и рестарта сервера.

[Akvel]

Совсем нет прелесть wtp в том что перезапускать сервер не надо, а редиплой произойдет на лету

[norguhtar]

Для spring и сервлетов? Что-то не заметил.

[Akvel]

Вы попробуйте на сервлетах, попробуете потом обсудим :-)

[norguhtar]

Я вообще каждый день пробую и не поверите оно редеплоит класс. А в случае spring надо еще и весь контекст перезагрузить.

[Akvel]

аа… вот вы к чему — согласен, редиплоится класс, но ведь это все происходит автоматически и не надо делать рестарт сервера или жмякать кнопку Publish (если вы конечно не отключили автопубликацию) — удобно же, пока переключаешься на браузер у тебя уже автоматом новая версия на локальном tomcat-е :-)

со спрингом честно не экспериментировал — не довелось, но все сервлеты, mb/dao классы редиплоятся на ура :-)

[norguhtar]

В случае spring это приводит к долгому redeploy, если конечно включен дебаг :)

[Gregy]

В Tapestry можно и без плагина все плюшки получить, в нём даже можно java классы на лету менять без redeploy, единственное когда нужен redeploy это если вы поменяли Entity классы.

[asolntsev]

Спорить не буду.
Если у вас это работает и вам это удобно использовать — используйте на здоровье.
Добавил к WTP ссылку на эту статью.