Добрый день,


Хотел спросить у вас что вы думаете по поводу довольно таки нового mvc-фреймворка play! для java-платформ? В чем его отличие и зачем нам еще один фреймворк спросите вы.

Дело в том что на данный момент есть много всякого mvc "добра" для java, но к сожалению возможно остановится только на нескольких фреймворках данного семейства. Сразу можно отбросить такие "чудеса" как Struts 1/2 или SpringMVC, т.к. это анти-продуктивные вещи, можно даже пойти дальше и сказать что каждый раз когда вы используете такой фреймворк ваше приложение, легким движением пальцев превращается в природный резерв/заповедник различных XML-конфигурационных файлов. В результате вы проводите больше времени за написанием различных конфигурационных файлов чем за написанием кода самого приложения.

Из "достойных" нашего внимания фреймворков можно выбрать Grails и #Roo(на данный момент мало что известно). Grails недавно приобретенный spring source, mvc фраймворк для java платформ, впитывающий в себя "лучшее" из Rails, и использующий концепции - convention over configuration. Все бы ничего, не есть у Grails одна большая проблема - это язык фреймворка т.е. groovy. Я не буду здесь вдаваться в подробности данного языка, лишь замечу что на момент написания данного поста groovy был в 60 ~ 300 раз медленнее java.

Далее есть один общий недостаток Grails и #Roo и других подобный продуктов - это servlet container standards. На сегодняшний день, почти нетронутых эволюцией, своего рода динозавры. Ну здесь тоже нечего сказать - это политика. А вот на практике получается что для простейшего приложения на Grails или SpringMVC (2 таблицы, GRUD, 4 формуляра, и пара страниц со списками) вам нужно выделить как минимум 128мб памяти вашего сервера приложений, иначе вам не избежать исключений типа "нехватка памяти", ну не смешно ли это?

Теперь вернемся к Play! . Рассмотрим несколько достоинств данного продукта :

1. Забудьте о servlet container standards, это позавчерашний день, play! базируется на Apache Mina но и его можно использовать на Google App Engine.

2. 100% Java - никаких примесей groovy подобной бесовщины.

3. HTTP, the Request/Response pattern, REST - стержень фреймворка.

4. Эффективный template engine.

5. Full-stack application framework - Поддержка JDBC, JPA, Memcache, WS(JSON/XML).

6. Архитектура встраиваемых модулей (плагинов)

Это лишь часть преимуществ, я приглашаю vas получше ознакомится с play! и поделится вашим мнением по поводу данного продукта.

--
Заранее вам благодарен

BlazkowiczДетские нападки на хорошо зарекомендовавшие себя фреймверки не делают рекламе чести. Оспорить можно каждый абзац. У Struts 2 и Spring MVC есть свои проблемы, но, судя по всему Play! их никак не решает.

Детские нападки - )))))))), "хорошо зарекомендовавшие себя фреймверки" а вам не кажется что они широко использовались лишь по тому что не было более продвинутых альтернатив ? Проблема оптимального использования серверных ресурсов по вашему это детские нападки ? Проблема сложности логики /читаемости кода приложения это тоже детские нападки.

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

А с чего вы взяли что Play! не решает проблем таких динозавров как Struts 2 и Spring MVC ? Play! например избавляет вас от писанины кучи ненужных конфигурационных файлов, это уже большой сдвиг вперед.

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

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

BlazkowiczПриехали. Реализацию нужно наследовать от классов фреймверка! А как же POJO??? Код становится абсолютно не реюзабельный.

Ну здесь вы заходите в более серьезные дебаты - какой подход лучше POJO или наследование от базовых классов модели. У каждого из подходов есть свои плюсы и минусы, мы выбрали второй подход, он нам показался лучше. Если для вас это минус, что же здесь ничего не поделать.

KachalovStern
Это лишь часть преимуществ, я приглашаю vas получше ознакомится с play! и поделится вашим мнением по поводу данного продукта.
- из описания не уловил какие требования к контейнеру: версия JVM, версия JSP/сервлетов, сколько надо ОП, способен ли работать на JVM со включенным SecurityManager-ом

1. версия JVM - вроде от 1.6 сейчас, раньше была 1.5
2. версия JSP/сервлетов - отсутствует, фреймворк не работает с конейнерами сервлетов
3. сколько надо ОП - последние тесты показали что хватает 30мб для среднестатистического форума, хотя все зависит от ситуации.

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

На вашу поделку обратили внимание а вы тут сразу "мазахист"... а вы, если вы автор этого чуда, не знаете и половины java best practice. Это сразу заметно.

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

BlazkowiczStern
Ну здесь вы заходите в более серьезные дебаты - какой подход лучше POJO или наследование от базовых классов модели.
Здесь вы пытаетесь сумничать, но при этом аргументировать чем такое наследование хорошо не можете.

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

Blazkowicz если вы автор этого чуда, не знаете и половины java best practice. Это сразу заметно.

java best practice - приведите пример. Скажите а grails/groovy java best practice на 100% применят или все же на 1% ? А например javassist тоже на 100% ? Или log4j ? Ищите идеала, вы мечтатель сударь .

BlazkowiczПотому что POJO имеет ряд несомненных преимуществ в плане тестирования и переиспользования кода. Фреймверки проповедующие наследование давно вымерли. А вы это называете прогрессом.

Послушайте я же вам объяснил что этот топик не для этого, хотите откройте другой по данной теме. Я не назвал именно эту часть прогрессом, но и не-прогрессом она не является. А с вашим мнением по данному поводу мы ознакомились, спасибо вам.

zalexakaSternизбавляет вас от писанины кучи ненужных конфигурационных файлов При использованиии аннотаций количество таковых вами сильно преувеличено

Да вы правы - аннотации это не идеальное решение, но все же это несравненно лучше чем куча конфигурационных файлов.

BlazkowiczДальше больше: фреймверк предлагает не создавать свойства в сущностях. Ему-то всё равно. А как нам потом эти сущности в бизнес логике-то использовать?

А можно поподробнее в чем вам такой подход не нравится?

Blazkowicz
Потому что POJO имеет ряд несомненных преимуществ в плане тестирования и переиспользования кода.

Если вы дочитаете документацию до конца то поймете что подход с наследованием не обязателен, но в 90% случаев более удобен(вам наверное трудно в это поверить) и экономит время. Но ничего вам не мешает иметь классы POJO с одной стороны и DAO с другой, только вам самим нужно будет с начала "собрать" вашу модель в jar и уж потом ее использовать на стороне контроллеров все как в Spring MVC

Blazkowicz
Наследование вместо POJO

Это скорее не java best practice а ?enterprise? best practice. Так как к самому языку отношения не имеют.
Blazkowicz

SternСкажите а grails/groovy java best practice на 100% применят или все же на 1% ? А например javassist тоже на 100% ? Или log4j ? Ищите идеала, вы мечтатель сударь .
Это ущербная позиция. Нужно выделятся среди всех качеством а не говорить, что остальные такой же отстой, так зачем делать лучше.
Я так понимаю вы никогда не слышали о концепции best effort. Цели которые мы поставили себе были достигнуты а именно - быстрота разработки и простота использования. Все ваши замечания мы обсудим но сразу должен вас заверить что двигаться по направлению SpringMVC (лишь бы следовать всем возможным бэст практисам) мы не будем.

Blazkowiczмне скучно, так что извините, что я продолжу.
Да пожалуйста, только у меня не всегда получается отвечать вовремя, скучать не приходится.

Blazkowicz
Stern1. Забудьте о servlet container standards, это позавчерашний день, play! базируется на Apache Mina но и его можно использовать на Google App Engine.
Это, в принципе, адекватная идея. Встречал такое неоднократно. Но еслибы Play! умел работать и на сервлетах, то было бы интересно.


Было такое дело в первых версиях, была у нас поддержка сервлет контейнеров, но она сильно тормозила улучшения, и доставляла много геморроя, так что ради всеобщего блага ей пришлось пожертвовать.

Blazkowicz
Stern3. HTTP, the Request/Response pattern, REST - стержень фреймворка.
REST для Web Service оно конечно хорошо. Только накой оно Web MVC фреймверку?

Ну как же ? А как насчет новых веяний типа функциональных тестов по средствам HTTP Request/Response. Но на данный момент 95% пользователей предпочитают обходится GET/POST, хотя REST подход в обычных приложениях добавляет больше порядка и лучше структурирует оное, хотя это мое мнение.

Blazkowicz

Stern4. Эффективный template engine.
Их есть у нас: Velocity, Freemarker, JSP, Wicket, Tapestry.
Все ну ооочень эффективные.


Вы уж простите но Velocity, Freemarker, JSP уж никак нельзя назвать эффективными. Единственная достойная в данном случае внимания вещь это groovy templates, но у них большой минус это groovy. Хотя в нашем фремворке мы частично их используем (в скриптах видов), пока без них не получается.

Blazkowicz
Stern5. Full-stack application framework - Поддержка JDBC, JPA, Memcache, WS(JSON/XML).
А если iBatis? А если EhCache? А если Spring-WS?


В принципе возможно но зачем ?

Blazkowicz

Stern
Это лишь часть преимуществ, я приглашаю vas получше ознакомится с play! и поделится вашим мнением по поводу данного продукта.

vas по ходу не придет.

Транслит коряво сработал.

BlazkowiczSternЯ так понимаю вы никогда не слышали о концепции best effort.
Я, так понимаю, вы ни один другой фреймверк толком не пробовали.


Почему же работал с SpringMVC и Grails, но я не понимаю какое это имеет отношения к планам и их реализациям play!

LeonidvНу вот я работаю, например, в Wicket. Никаких конфигурационных файлов для настройки самого Wicket не пишу. Конечно, я прикручиваю Spring для интеграции с ORM и подобного, но самому Wicket'у это перпендикулярно.

Отсюда вопрос - чем ваш движок лучше Wicket?

Wicket насколько я помню component-based а play! это MVC-фреймворк, вот как бы одно главное отличие. Я никогда не использовал этот Wicket, но слышал что он тоже достаточно легок физически и в использовании, но он остается все таки сервлет-контейнер зависимым.

KachalovSternно он остается все таки сервлет-контейнер зависимым.
- лично я считаю это достоинством, так как сервера приложений не дураки пишут и возможность использовать все что положено по спецификации JavaEE это достоинство, а не недостаток. Рекламируемый Вами фреймворк не умеет даже логировать HTTP-запросы (я так понял по отсутствию ответа на прямо заданный вопрос), без чего невозможно говорить о нормальной работе web-проекта (анализ посещаемости, генерация Sitemap, отслеживание подозрительной активности и т. п.) - а это стандартная возможность web-сервера и сколько еще таких возможностей Вы зарезали написав самодельный web-сервер, а точнее самодельный контейнер самодельных компонентов?

Простите но мне тут очень много разных людей вопросы задают за всеми не поспеть. Я не знаю насколько Apache Mina самодельный и насколько он режет всякий ненужный хлам типа отслеживание посещаемости или активности или сервер сессий итд. Вот вы здесь говорили про нормальный веб проект с чего вы взяли что вышеописанные возможно должны быть представлены в проекте, вы еще скажите что JMX это тоже неотъемлемая часть нормального для вас проекта. Если вам нравится засорять окружающую среду имея 10 серверов для одного приложения форма или блога, то пожалуйста продолжайте, но вот не надо говорить что это нормально.

Blazkowicz
Для этого есть Seam, если говорить об application framework и tapestry если говорить про Web Framework.


Я зашел на страничку горячо любимого вами Seam, на первой же линии что я увидел :

Seam is a powerful open source development platform for building rich Internet applications in Java. Seam integrates technologies such as Asynchronous JavaScript and XML (AJAX), JavaServer Faces (JSF) , Java Persistence (JPA), Enterprise Java Beans (EJB 3.0) and Business Process Management (BPM) into a unified full-stack solution, complete with sophisticated tooling.

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

KachalovSternнасколько он режет всякий ненужный хлам типа отслеживание посещаемости
...
но вот не надо говорить что это нормально.
- эээ батенька, web-программирование это не только программирование.

Послушайте насчет логов посещений, вам же было сказано что проект построен на apache mina, я не узнавал поддерживает ли он такую настройку, думаю что нет, вы зайдите и почитайте документацию, но в play! пока такой поддержки нет. Ваши SEO шники это сколько процентов от рынка веб приложений, 0.01% ? И с каких это пор веб-программирование (касательно серверной части) должно базироваться на ултракомлексных решениях, это скорее исключение чем правило, статистика.

Доктор Азбарагуз,

А с чего вы взяли что речь идет об обратном или противоречит вашему вопросу ?

Blazkowicz
Apache MINA это Networking Framework.
Play! же позиционирует себя как Http Server поверх этого фреймверка. Но при этом никакой функциональности Http Server-а enterprise уровня он не предоставляет. Из чего можно продоложить что без обертки в Apache он функционировать в продакшне не сможет.

В целом оно так, одна поправка - Http Server-а enterprise уровня в понятии java платформ.

LeonidvSternWicket насколько я помню component-based а play! это MVC-фреймворк, вот как бы одно главное отличие. Я никогда не использовал этот Wicket, но слышал что он тоже достаточно легок физически и в использовании, но он остается все таки сервлет-контейнер зависимым.
Если верить wikipedia, то Wicket MVC framework. Более того, авторы Wicket (разработчики Swing) вроде как заявляют что Wicket true MVC (в отличие от Swing).

В чем отличие между компонентым и MVC фреймворками?

Дык как бы заходя на первую страницу в викепедии вижу следующее : Apache Wicket is a lightweight component-based web application framework for the Java programming language conceptually similar to JavaServer Faces and Tapestry.

Ну ваш вопрос довольно комплексный. Пример такого дубового компонентного фреймворка это JavaServer Faces или ,простите за сравнение ничего другого в голову не приходит, ASP.NET. А пример MVC паттерн можно найти в таких фреймворках как springMVC или Grails.