Комментарии 38
Неплохое решение, но для Java разработчиков есть очень удобный playframework, который является новым шагом в мире Java framework'ов, думаю он заслуживает внимание.
-1
Он прикольный, но это вещь в себе, новая платформа для разработки. С таким же успехом можно посоветовать, например, писать на Django.
0
речь идет о быстрой разработки веб приложений на Джава, и это единственный фреймворк который позволит это делать.
0
Ни одного, ни малейшего, даже в названиях, отличия от Spring MVC. Причем еще старой версии, 2.х, которой в обед сто лет. При этом фреймворк свежий, а значит плохо отлаженный и с минимальной базой пользовательского опыта работы с ним (и решения его проблем) в Сети. Быстро на нем только заглавную страничку налабать можно будет, а после первой же проблемы начнутся… проблемы.
-1
с чего вы взяли?
0
С чего я взял что? Что нет отличий? Полистал фреймворк. Он типовой, каких десятки — в веб-разработке сейчас новое слово довольно сложно сказать. Что начнутся проблемы? Это аксиома, я на самом деле не хочу говорить об этом. Что эти проблемы сложнее будет решать? Решение любой нетиповой (не разобранной в туториале) проблемы сейчас находится одним из двух способов: 1) в книжке "… in Action" издательства O'Reilly, которой нет; и 2) в Сети, и тогда количество решенных проблем (и скорость нахождения решения) напрямую зависят от возраста фреймворка. Которым данный экземпляр похвастаться тоже не может.
Детально: в основе у нас что? MVC, классы контроллеров. На морде у нас что? Темплейтный движок «мы не жсп». К базе мы как? По javax.persistance, как все. Валидируемся мы как? Аннотациями JSR-303, причем клиентскую валидацию мы не умеем (как все, однако для того же спринга способ прикрутить клиентскую валидацию по тем же JSR-303 есть — потому что возраст системы способствует; а для этого фреймворка?).
Я не говорю, что фреймворк плохой. Я просто говорю, что он такой же. Как все. Со своими проблемами, которые он специально затачивался, чтобы решать, и со своими уникальными проблемами, которых нет у кого-то еще. Как обычно.
Детально: в основе у нас что? MVC, классы контроллеров. На морде у нас что? Темплейтный движок «мы не жсп». К базе мы как? По javax.persistance, как все. Валидируемся мы как? Аннотациями JSR-303, причем клиентскую валидацию мы не умеем (как все, однако для того же спринга способ прикрутить клиентскую валидацию по тем же JSR-303 есть — потому что возраст системы способствует; а для этого фреймворка?).
Я не говорю, что фреймворк плохой. Я просто говорю, что он такой же. Как все. Со своими проблемами, которые он специально затачивался, чтобы решать, и со своими уникальными проблемами, которых нет у кого-то еще. Как обычно.
0
Разработка на нем ведется в разы быстрее чем на спринге.
Он взял все самое лучшее из рельсов. А ваши проблемы в любом фреймворке есть.
Он взял все самое лучшее из рельсов. А ваши проблемы в любом фреймворке есть.
0
> Разработка на нем ведется в разы быстрее чем на спринге.
Ну вот как, как она там может вестись быстрее, если в нем точно такие же: а) ORM-слой, б) бизнес-логика, в) темплейты вьюх? В чем разница, может, я упустил что-то?
> А ваши проблемы в любом фреймворке есть.
Ну так я об этом и говорю.
Ну вот как, как она там может вестись быстрее, если в нем точно такие же: а) ORM-слой, б) бизнес-логика, в) темплейты вьюх? В чем разница, может, я упустил что-то?
> А ваши проблемы в любом фреймворке есть.
Ну так я об этом и говорю.
-1
Вы не видели кажется этот фреймворк в действии.
Да он использует почти все тоже самое, но обертки которые там сделаны, увеличивают простоту кода и скорость разработки. Ну и тем самым облегчает жизнь разработчику.
Да он использует почти все тоже самое, но обертки которые там сделаны, увеличивают простоту кода и скорость разработки. Ну и тем самым облегчает жизнь разработчику.
0
Вы какими-то очень общими фразами говорите. «Обертки, которые там», «увеличивают простоту и скорость», «разработка в разы быстрее», «лучшее из рельсов» (этим только ленивый кстати не кичится нынче). Я же изучил референс по этому фреймворку, и никакой магии там не обнаружил, все точно такое же, более того: я могу при необходимости глава-в-главу сопоставить, со ссылками, референсы по spring и по play. Но я действительно на практике с ним не работал, и пытаюсь понять, стоит ли овчинка изучения. И вполне допускаю, что вижу среди всего массива данных об этом фреймворке только знакомое, оттого у меня такое, возможно неверное, впечатление о нем. Так давайте говорить предметно, какие конкретные фичи улучшают производительность программиста в play? Какие-то может быть утилити классы, или инструменты, или архитектурные решения вы конкретные можете назвать?
0
как минимум там есть crud для классов моделей.
0
ушел со спринга до того, как это появилось. Это что генератор кода чтоли?
0
Я хочу акцентировать внимание на том, что приложения разрабатываются по большому счету не то, что на языке, а на платформе. Сам же язык — штука второстепенная.
+1
А если проект Ant + Ivy + IDEA, добиться запуска прямо из IDE не получается из за сотен внешних зависимостей?
+1
>я использую WTF
Точно WTF? Или все-таки WTP? :)
Точно WTF? Или все-таки WTP? :)
+6
>Все обновления подхватываются на лету
Это чисто маркетинговый ход. В любом фреймворке с таким механизмом есть заранее оговоренные ограничения и точно не все обновления подхватываются на лету.
Это чисто маркетинговый ход. В любом фреймворке с таким механизмом есть заранее оговоренные ограничения и точно не все обновления подхватываются на лету.
+1
+1 за PlayFramework. Особенно хорош в связке со Scala
+1
Вы забыли про самый основной недостаток — это все под Eclipse. Очень много людей использует Netbeans, еще, наверное, больше IDEA. А еще в одной команде могут быть разработчики на разных IDE. Поэтому предыдущее решение мне понравилось больше, только было бы здорово, если бы был пример конфига для maven.
+2
Я не до конца понял: вот добавил я модельный класс, DAO, какой-нибудь сервис, контроллер и шаблон — после этого я смогу в браузере нажать F5 и все заработает без какого-либо редеплоймента? Браузер отобразит новую страницу за секунду или менее?
+1
Будет redeployment. Изменения на лету подхватываются только в jsp. Все что лежит в классах требует редеплоймента и рестарта сервера.
0
Совсем нет прелесть wtp в том что перезапускать сервер не надо, а редиплой произойдет на лету
0
Для spring и сервлетов? Что-то не заметил.
0
Вы попробуйте на сервлетах, попробуете потом обсудим :-)
0
Я вообще каждый день пробую и не поверите оно редеплоит класс. А в случае spring надо еще и весь контекст перезагрузить.
0
аа… вот вы к чему — согласен, редиплоится класс, но ведь это все происходит автоматически и не надо делать рестарт сервера или жмякать кнопку Publish (если вы конечно не отключили автопубликацию) — удобно же, пока переключаешься на браузер у тебя уже автоматом новая версия на локальном tomcat-е :-)
со спрингом честно не экспериментировал — не довелось, но все сервлеты, mb/dao классы редиплоятся на ура :-)
со спрингом честно не экспериментировал — не довелось, но все сервлеты, mb/dao классы редиплоятся на ура :-)
0
В Tapestry можно и без плагина все плюшки получить, в нём даже можно java классы на лету менять без redeploy, единственное когда нужен redeploy это если вы поменяли Entity классы.
0
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
По следам поста «Быстрая разработка веб-приложений на Java»