Согласен но раньше были и минусы такого подхода, я думаю что модули вернутся но вот в каком виде? Не знаю конечно что из себя представляет данный проект но вот например урезанная версия play 2.0 для rest. А так то верно что они поспешили с выходом 2.0.
Сыровато то он сыровато, но вот невозможность генерирования war это не недароботка а скорее наведение порядка, все хватить деплоить в j2ee, а не нравится пользуйте спринг роу или что то вроде этого. War в play! это пережиток того времени когда сам фреймворк был эмбрионом и использовался в банке в купе с вебсферой. Все хватить вводить людей в заблуждение и лелеять их пустыми надеждами, приложения для netty и j2ee несовместимы!..
Плюс ebean в том что он легче hibernate так как не имеет например сессий (я правда им давно не пользовался с 2010).
А насчет поддержи модулей обождите оно еще вернется, но вот такие модули как поддержка мувена я бы самолично в печь отправлял.
Согласен с вами по поводу движка шаблонов, я сам не понял зачем нужно было это делать, тем более вокруг столько всего уже есть, scalate например (взяли бы его за основу). Тоже самое anorm я так и не понял зачем он понадобился, меня уверяли что это достойная замена орм но для языков с функциональной парадигмой но думаю что эта цель не была достигнута в реализации. По мне так ScalaQuery подходит лучше как замена jpa.
Про развертывание в продакшене тоже постараюсь написать как только закончу очередной проект и на его примере представлю все. Может даже с интеграцией в шеф если интерестно.
Не совсем обратно несовместим, код каторый вы пишете будет несовместим т.к как вы видели очень много поменялось, например теперь метод-экшен должен возвращать результат, редирект более не делается прямым вызовом экшена итд. Остались кирпичики из версии 1.* которые просто перекочевали в версию 2.0, но для финального пользователя наступили координальные изменения. Все это ради достижения принципа java == scala (пропорциональность частей).
С моей точки зрения для такого языка как scala использование jpa не совсем приемлемо. Я не говорю что это невозможно просто подумайте чего стоит достижение immutability в сущнастях jpa, это возможно (сам этого достигал) но какой ценой? Так же одна из основных причин это тяжеловесность jpa и его несовместимость с ActiveRecord à la RoR. Вообще разговоры о «выкидывании» jpa из play core идут уже с версии 1.1.
Согласен но раньше были и минусы такого подхода, я думаю что модули вернутся но вот в каком виде? Не знаю конечно что из себя представляет данный проект но вот например урезанная версия play 2.0 для rest. А так то верно что они поспешили с выходом 2.0.
Сыровато то он сыровато, но вот невозможность генерирования war это не недароботка а скорее наведение порядка, все хватить деплоить в j2ee, а не нравится пользуйте спринг роу или что то вроде этого. War в play! это пережиток того времени когда сам фреймворк был эмбрионом и использовался в банке в купе с вебсферой. Все хватить вводить людей в заблуждение и лелеять их пустыми надеждами, приложения для netty и j2ee несовместимы!..
Плюс ebean в том что он легче hibernate так как не имеет например сессий (я правда им давно не пользовался с 2010).
А насчет поддержи модулей обождите оно еще вернется, но вот такие модули как поддержка мувена я бы самолично в печь отправлял.
Согласен с вами по поводу движка шаблонов, я сам не понял зачем нужно было это делать, тем более вокруг столько всего уже есть, scalate например (взяли бы его за основу). Тоже самое anorm я так и не понял зачем он понадобился, меня уверяли что это достойная замена орм но для языков с функциональной парадигмой но думаю что эта цель не была достигнута в реализации. По мне так ScalaQuery подходит лучше как замена jpa.