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 платформ.