Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 37
А почему вы не рекомендуете использовать JPA?
С моей точки зрения для такого языка как scala использование jpa не совсем приемлемо. Я не говорю что это невозможно просто подумайте чего стоит достижение immutability в сущнастях jpa, это возможно (сам этого достигал) но какой ценой? Так же одна из основных причин это тяжеловесность jpa и его несовместимость с ActiveRecord à la RoR. Вообще разговоры о «выкидывании» jpa из play core идут уже с версии 1.1.
Использовать можно, но это будете как минимум постоянно напарываться на проблемы совместимости типов, особенно это касается коллекций. Implicit convertions и все такое… не очень хорошо, поверьте.
Было бы очень интересно почитать как об истории фреймворка, так и более детальные обзоры некоторых аспектов его использования!
Спасибо за этот чертовски хороший фреймворк! Я уже больше года использую Play, в основном это были простые сайты. Сейчас я разрабатываю довольно высоконагруженный сервис, используя пока Play 1.2.4. Сам сервис построен на следующей архитектуре: сервер — API — клиент. Где клиентом можеть быть как веб-сайт, так и мобильное приложение. Веб-сайт представляет собой довольно сложное одностраничное приложение. Мне кажется, что сейчас Play как раз и движется в этом направлении, стремясь использовать как можно больше асинхронного HTTP.
Очень интересно было бы услышать про продакшен, а так же про ORM и почему отказались от Hibernate.
Очень интересно было бы услышать про продакшен, а так же про ORM и почему отказались от Hibernate.
совсем выпилили хибернейт? play2 обратно не совместим с кодом, написанным для более ранних версий?
Я неправильно выразился, извиняюсь. Не отказались, а
Насколько я понимаю, несовместим лишь частично, это такие вещи как контроллеры, роутер.
Не совсем обратно несовместим, код каторый вы пишете будет несовместим т.к как вы видели очень много поменялось, например теперь метод-экшен должен возвращать результат, редирект более не делается прямым вызовом экшена итд. Остались кирпичики из версии 1.* которые просто перекочевали в версию 2.0, но для финального пользователя наступили координальные изменения. Все это ради достижения принципа java == scala (пропорциональность частей).
Обратно не совместим. Хибернейт заменили на Agaje Ebean — JPA фреймворк со странными перспективами. Вторая версия сильно не доработана, например не умеет генерировать war, нет популярных модулей вроде CRUD, Security.
В общем сыровато.
В общем сыровато.
kai,
Сыровато то он сыровато, но вот невозможность генерирования war это не недароботка а скорее наведение порядка, все хватить деплоить в j2ee, а не нравится пользуйте спринг роу или что то вроде этого. War в play! это пережиток того времени когда сам фреймворк был эмбрионом и использовался в банке в купе с вебсферой. Все хватить вводить людей в заблуждение и лелеять их пустыми надеждами, приложения для netty и j2ee несовместимы!..
Плюс ebean в том что он легче hibernate так как не имеет например сессий (я правда им давно не пользовался с 2010).
А насчет поддержи модулей обождите оно еще вернется, но вот такие модули как поддержка мувена я бы самолично в печь отправлял.
Сыровато то он сыровато, но вот невозможность генерирования war это не недароботка а скорее наведение порядка, все хватить деплоить в j2ee, а не нравится пользуйте спринг роу или что то вроде этого. War в play! это пережиток того времени когда сам фреймворк был эмбрионом и использовался в банке в купе с вебсферой. Все хватить вводить людей в заблуждение и лелеять их пустыми надеждами, приложения для netty и j2ee несовместимы!..
Плюс ebean в том что он легче hibernate так как не имеет например сессий (я правда им давно не пользовался с 2010).
А насчет поддержи модулей обождите оно еще вернется, но вот такие модули как поддержка мувена я бы самолично в печь отправлял.
Вы ошибаетесь, поддержка WAR будет в 2.1, сейчас просто не успевают. Хочешь не хочешь, а вокруг дофига аппликейшн-серверов, в которые war кидать можно легко и непринужденно. Про пережитки — это ваши личные фантазии.
Модули тоже будут, но потом. В общем они спешили выпустить версию 2.0, отложив на время некоторые фишки, критичные для значительной части коммунити.
Модули тоже будут, но потом. В общем они спешили выпустить версию 2.0, отложив на время некоторые фишки, критичные для значительной части коммунити.
kai,
Ну тут наверное воля большинства взяла свое, хотя про полное желание искоренить поддержку j2ee я слышу от господина Bort уже с версии 1.1 наверное, вот думал наконец то порадовал, аль нет.
А я вам про что говорю, модули на потом, но вот честно никто мне пока точного ответа как они будут выглядеть не дал, т.е. гдать пока на эту тему не вижу смысла
Ну тут наверное воля большинства взяла свое, хотя про полное желание искоренить поддержку j2ee я слышу от господина Bort уже с версии 1.1 наверное, вот думал наконец то порадовал, аль нет.
А я вам про что говорю, модули на потом, но вот честно никто мне пока точного ответа как они будут выглядеть не дал, т.е. гдать пока на эту тему не вижу смысла
1. Это не «воля большинства», это суровая необходимость. И я не вижу причин считать, что WAR это плохо.
2. Модули там уже есть, но это не модули Play, а модули SBT, со всеми вытекающими.
2. Модули там уже есть, но это не модули Play, а модули SBT, со всеми вытекающими.
kai,
Вы ведь знакомы с play, с принципапи работы netty, mina, grizly и вы должны понимать что если в вашем приложении вы хотите использовать к примеру WebSocket или хотите что написать банальный чат способный выдерживать десятки тысяч одновременных подключений или же ищете асанхронизма то не о каком развертывании play приложения в j2ee контейнере не может быть и речи. Цитируя создателя play, которого всегда передергивает от упоминания про j2ee — «не вижу ни малейшего смысла использовать play с j2ee, актуальная поддержка (речь шла о 1.1) имеется как вынужденная временная мера, но я вам не советую использовать play с j2ee». Конец цитаты, было сказанно почти на всех jug на которых я присутствовал с господином Bort. Но не будем отдалятся от сути и развязывать святых войн. Создатели play не рекомендуют вам использовать онный с j2ee, но если у вас действительно нет другого выбора то используйте.
Так же по мудлям можно использовать и старые добрые jars :) При условии если у вас не бует конфликтов имен.
Вы ведь знакомы с play, с принципапи работы netty, mina, grizly и вы должны понимать что если в вашем приложении вы хотите использовать к примеру WebSocket или хотите что написать банальный чат способный выдерживать десятки тысяч одновременных подключений или же ищете асанхронизма то не о каком развертывании play приложения в j2ee контейнере не может быть и речи. Цитируя создателя play, которого всегда передергивает от упоминания про j2ee — «не вижу ни малейшего смысла использовать play с j2ee, актуальная поддержка (речь шла о 1.1) имеется как вынужденная временная мера, но я вам не советую использовать play с j2ee». Конец цитаты, было сказанно почти на всех jug на которых я присутствовал с господином Bort. Но не будем отдалятся от сути и развязывать святых войн. Создатели play не рекомендуют вам использовать онный с j2ee, но если у вас действительно нет другого выбора то используйте.
Так же по мудлям можно использовать и старые добрые jars :) При условии если у вас не бует конфликтов имен.
Забыл добавить, в Play 2.0 напрочь выпилили модули, как это было в 1.х. Теперь нет удобного разбиения на модули, со своими роутами и прочим.
kai,
Согласен но раньше были и минусы такого подхода, я думаю что модули вернутся но вот в каком виде? Не знаю конечно что из себя представляет данный проект но вот например урезанная версия play 2.0 для rest. А так то верно что они поспешили с выходом 2.0.
Согласен но раньше были и минусы такого подхода, я думаю что модули вернутся но вот в каком виде? Не знаю конечно что из себя представляет данный проект но вот например урезанная версия play 2.0 для rest. А так то верно что они поспешили с выходом 2.0.
В первой версии нужно было все роуты из модуля подключать вручную, но зато сразу все. Во второй это не поддерживается в принципе. А текущая реализация суброектов на sbt вызывает очень много вопросов. Очень сырая, если говорить проще. Обещают в будущем проработать этот вопрос.
В общем я бы на второй версии пока бы ничего серьезного не писал бы. Так, поиграть, познакомиться, скалу помучать.
В общем я бы на второй версии пока бы ничего серьезного не писал бы. Так, поиграть, познакомиться, скалу помучать.
Про развертывание в продакшене тоже постараюсь написать как только закончу очередной проект и на его примере представлю все. Может даже с интеграцией в шеф если интерестно.
Напишите обязательно про известные ошибки и недочеты, например про проблемы конфигурации JNDI. И несовместимость с Java7, про проблемы с x64. И про проблемы с перегрузкой экшенов.
Хотя в 1.5 обещали это частично исправить.
Хотя в 1.5 обещали это частично исправить.
Про java7 это не проблема play а скорее tools которые фреймворк использует, а как вам известно он использует компилятор от eclipse для динамической компиляции изменения и javasist (что коллатерально) для некоторых фич. Я даже не знаю есть ли уже стабильная версия эклипс компилятора для версии 7. А теперь представте работу которую нужно проделать что бы все это интегрировать, хотите помогите сообществу будем только рады. Лично я предпочитаю видеть как play эволюционирует в сторону scala чем в сторону java 7, пора кончать с java :).
Меня, как ендюзера фреймворка, это волнует очень мало. Я вижу, что есть проблемы с Java7, что есть проблемы с x64. И на это не нужно обижаться или оправдывать.
Это нужно учитывать, как свойство Play Framework 1.x ветки.
Это нужно учитывать, как свойство Play Framework 1.x ветки.
kai,
Да я и не обижаюсь, и не оправдываю, стараюсь объяснить как есть. Пока поддержка Java7 не может чисто физически быть в приоритетах так как почти вся команда разработчиков брошена на play 2. А поддержкой (именно поддержкой) веток 1.* занимается всего пара человек. Но я бы не стал говорить что вторая версия вообще непригодна для реальных проектов, использовать можно но на больших проектах могут возникнуть неудобства.
Да я и не обижаюсь, и не оправдываю, стараюсь объяснить как есть. Пока поддержка Java7 не может чисто физически быть в приоритетах так как почти вся команда разработчиков брошена на play 2. А поддержкой (именно поддержкой) веток 1.* занимается всего пара человек. Но я бы не стал говорить что вторая версия вообще непригодна для реальных проектов, использовать можно но на больших проектах могут возникнуть неудобства.
А можно в двух словах про проблемы с x64?
Сталкивался с проблемами с Java 7, но не встречал проблем с x64, хотя уже полгода делаю проект на ноутбуке с Windows 7 x64.
Сталкивался с проблемами с Java 7, но не встречал проблем с x64, хотя уже полгода делаю проект на ноутбуке с Windows 7 x64.
Я работал с веткой 1.2, и 2.0 меня местами очень сильно разочаровал. Шаблонный движок это просто позор, учитывая то, что он написан на одном из лучших языков для построения DSL – на Scala. Вот вам пример, чтоб не быть голословным:
Все отлично, теперь делаем вот так:
И получаем:
Я напоролся на это немного по-другому (в карированном заголовке) и понять почему возникает именно такое исключение было немного трудновато. И потом – новые шаблоны требуют постоянной компиляции, что удлинняет процесс «изменил шаблон»->«проверил в браузере». Шаблоны на Groovy потом тоже компилировались, но на этапе разработки с ними было гораздо проще. Единственное что — старые шаблоны вроде как сообщество портирует под вторую ветку. Ну и последнее – когда «весь мир» идет в сторону полностью декларативного стиля описания шаблонов (см. шаблоны в Lift, Enlive для Clojure) нам предлагают вернуться к JSP и делать @import в шаблонах(!!!).
Роутинг стал хуже, потому что стал EDSL, но это чисто субъективно.
Но есть и хорошее, например (незаслуженно не упомянутые в статье) формы – я бы именно это считал киллер-фичей 2.0. Теперь появился очень, очень удобный механизм валидирования входных данных (оно и раньше было, просто не так удобно, ну и теперь это явно отдельная сущность).
Anorm пробовал пару месяцев назад — исчезающе мало документации, хаутушек и примеров.
@main("Welcome to Play 2.0") {Все отлично, теперь делаем вот так:
@main("Welcome to Play 2.0")
{И получаем:
sbt.PlayExceptions$CompilationException: Compilation error [missing arguments for method apply in object main; Я напоролся на это немного по-другому (в карированном заголовке) и понять почему возникает именно такое исключение было немного трудновато. И потом – новые шаблоны требуют постоянной компиляции, что удлинняет процесс «изменил шаблон»->«проверил в браузере». Шаблоны на Groovy потом тоже компилировались, но на этапе разработки с ними было гораздо проще. Единственное что — старые шаблоны вроде как сообщество портирует под вторую ветку. Ну и последнее – когда «весь мир» идет в сторону полностью декларативного стиля описания шаблонов (см. шаблоны в Lift, Enlive для Clojure) нам предлагают вернуться к JSP и делать @import в шаблонах(!!!).
Роутинг стал хуже, потому что стал EDSL, но это чисто субъективно.
Но есть и хорошее, например (незаслуженно не упомянутые в статье) формы – я бы именно это считал киллер-фичей 2.0. Теперь появился очень, очень удобный механизм валидирования входных данных (оно и раньше было, просто не так удобно, ну и теперь это явно отдельная сущность).
Anorm пробовал пару месяцев назад — исчезающе мало документации, хаутушек и примеров.
helions8,
Согласен с вами по поводу движка шаблонов, я сам не понял зачем нужно было это делать, тем более вокруг столько всего уже есть, scalate например (взяли бы его за основу). Тоже самое anorm я так и не понял зачем он понадобился, меня уверяли что это достойная замена орм но для языков с функциональной парадигмой но думаю что эта цель не была достигнута в реализации. По мне так ScalaQuery подходит лучше как замена jpa.
Согласен с вами по поводу движка шаблонов, я сам не понял зачем нужно было это делать, тем более вокруг столько всего уже есть, scalate например (взяли бы его за основу). Тоже самое anorm я так и не понял зачем он понадобился, меня уверяли что это достойная замена орм но для языков с функциональной парадигмой но думаю что эта цель не была достигнута в реализации. По мне так ScalaQuery подходит лучше как замена jpa.
Было бы интересно узнать про использование Play в продакшене
Про Anorm было бы очень интересно
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Обзор новых возможностей в playframework v2