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

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

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

> А ваши проблемы в любом фреймворке есть.
Ну так я об этом и говорю.
Вы не видели кажется этот фреймворк в действии.
Да он использует почти все тоже самое, но обертки которые там сделаны, увеличивают простоту кода и скорость разработки. Ну и тем самым облегчает жизнь разработчику.
Вы какими-то очень общими фразами говорите. «Обертки, которые там», «увеличивают простоту и скорость», «разработка в разы быстрее», «лучшее из рельсов» (этим только ленивый кстати не кичится нынче). Я же изучил референс по этому фреймворку, и никакой магии там не обнаружил, все точно такое же, более того: я могу при необходимости глава-в-главу сопоставить, со ссылками, референсы по spring и по play. Но я действительно на практике с ним не работал, и пытаюсь понять, стоит ли овчинка изучения. И вполне допускаю, что вижу среди всего массива данных об этом фреймворке только знакомое, оттого у меня такое, возможно неверное, впечатление о нем. Так давайте говорить предметно, какие конкретные фичи улучшают производительность программиста в play? Какие-то может быть утилити классы, или инструменты, или архитектурные решения вы конкретные можете назвать?
как минимум там есть crud для классов моделей.
ушел со спринга до того, как это появилось. Это что генератор кода чтоли?
Угум. Ну, в том числе. Это та самая «умная» составляющая из рельсов, которая пытается облегчить рутину. Но Roo уже несколько лет, если вы пользовались Spring старых версий, до ну хотя бы 2.5, то я могу понять причину наших разногласий. :)
последняя версия с которой я работал была 2.5, но 3.0 я смотрел и ничего кроме аннотаций не видел. Но я все такие о фреймворке, а не о генераторе. Такой генератор можно для всего сделать, но если смотреть чисто на фреймворк.
… ииии да. Согласен.
Я хочу акцентировать внимание на том, что приложения разрабатываются по большому счету не то, что на языке, а на платформе. Сам же язык — штука второстепенная.
А если проект Ant + Ivy + IDEA, добиться запуска прямо из IDE не получается из за сотен внешних зависимостей?
На счет Ivy, не знаю не пробовал

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

Точно WTF? Или все-таки WTP? :)
WTF лучше :)
Упс :-) Исправился!
>Все обновления подхватываются на лету

Это чисто маркетинговый ход. В любом фреймворке с таким механизмом есть заранее оговоренные ограничения и точно не все обновления подхватываются на лету.
+1 за PlayFramework. Особенно хорош в связке со Scala
На Scala есть знаменитый Lift. Впринципе, разрабатывать еще быстрее, чем на Play, если ты разработчик этого самого Lift )) Для новичков же настолько неудобоварим, что заморачиваться даже не стоит. Как впрочем и практически любая либа на scala, пестрящая закорючками и DSL-ями.
Вы забыли про самый основной недостаток — это все под Eclipse. Очень много людей использует Netbeans, еще, наверное, больше IDEA. А еще в одной команде могут быть разработчики на разных IDE. Поэтому предыдущее решение мне понравилось больше, только было бы здорово, если бы был пример конфига для maven.
Я бы даже больше сказал — это основной плюс.
С использование различный сред в команде это никак не связано, это дело каждого где и как вести разработку — я лишь делюсь опытом.
Я не до конца понял: вот добавил я модельный класс, DAO, какой-нибудь сервис, контроллер и шаблон — после этого я смогу в браузере нажать F5 и все заработает без какого-либо редеплоймента? Браузер отобразит новую страницу за секунду или менее?
Будет redeployment. Изменения на лету подхватываются только в jsp. Все что лежит в классах требует редеплоймента и рестарта сервера.
Совсем нет прелесть wtp в том что перезапускать сервер не надо, а редиплой произойдет на лету
Для spring и сервлетов? Что-то не заметил.
Вы попробуйте на сервлетах, попробуете потом обсудим :-)
Я вообще каждый день пробую и не поверите оно редеплоит класс. А в случае spring надо еще и весь контекст перезагрузить.
аа… вот вы к чему — согласен, редиплоится класс, но ведь это все происходит автоматически и не надо делать рестарт сервера или жмякать кнопку Publish (если вы конечно не отключили автопубликацию) — удобно же, пока переключаешься на браузер у тебя уже автоматом новая версия на локальном tomcat-е :-)

со спрингом честно не экспериментировал — не довелось, но все сервлеты, mb/dao классы редиплоятся на ура :-)
В случае spring это приводит к долгому redeploy, если конечно включен дебаг :)
В Tapestry можно и без плагина все плюшки получить, в нём даже можно java классы на лету менять без redeploy, единственное когда нужен redeploy это если вы поменяли Entity классы.
Спорить не буду.
Если у вас это работает и вам это удобно использовать — используйте на здоровье.
Добавил к WTP ссылку на эту статью.
Только полноправные пользователи могут оставлять комментарии.
Войдите, пожалуйста.