Граждане! Помогите определиться с фреймворком для приложения.
Это веб сайт, в котором есть выставленная в интернет для общего обозрения часть - собственно магазин.
А внутри много разных людей обрабатывает эти заказыб имея свою роль, видя свои шаги в процессах и принимая определенные решения, кликая на какой-нить Next   и процесс ушел к другой роли  и  уже другой человек его вилит - и тд и тп. То есть по сути workflow - но с интерфейсом в интернете, где покупатели точно также учавствуют вв этом workflow и имеют свои шаги и интерфейсы.
Хотел использовать Seam - но народ говорит, что монолитный, тяжеловесный и ошибки кидает невразумительные периодически - и хотят съезжать с него. Посоветовали "Grails или SpringMVC как наиболее современные и качественные".
Посмотрел что такое Grails - что-то из семейства Spring. 

Подскажите пожалуйста, какую роль в таком проекте может занять Grails, есть ли ему вообще место в такого плана проекте, и как он связан с другими продуктами Spring - то есть надо использовать и другие Springi типа SpringMVC и тп?

Gails сделан на основе Spring MVC.

В нем можно подключать модули, коих большое количество, уверен, что и для ecommerce их немало. И еще один плюс - это язык Groovy, на котором он написан. После него java такой многословный и много чего в нем не хватает. И Groovy для java программистов дается очень легко, можно сразу садиться и писать.

Не совсем понял. Так это уже не Java? А если я захочу потом на view уровне подключить GWT например - то уже не получится? То есть буду жестко привязан уже к Grails,  к тому что предлагает именно он и не смогу даже при необходимости SpringMVC подключить?

Нет, не джава, JVM-based язык. Сам лично GWT не подключал, но ходят слухи, что можно. А вообще я пытался на груви писать для GWT, правда только серверную часть - вполне сносно. 

То есть на базе Spring сделали новый язык?

Нет, не на базе. http://ru.wikipedia.org/wiki/Groovy
Это самостоятельный язык с динамической типизацией. А grails просто написан на нем. Мне понравился grails.
http://grails.org/doc/latest/guide/6.%20Th...0Layer.html#6.5 Web Flow

GWT подключить получится. (сам, правда не подключал - подключал Vaadin, который в свою очередь основан на GWT)

По сути Grails это обертка из Groovy над Spring-ом.  Если нужно что-то не стандартное - всегда можно влезть внутрь.

Добавлено через 2 минуты и 58 секунд


Крайне не согласен с утверждением в википедиа:


Никакая Groovy не альтернатива! Он дополнение. Вполне органично сосуществующее с Java. 

Альтернатива - это Scala. 

Не надо так категорично. 
Альтернатива это ведь не замена.

То есть вот стоит задача - сделать этот веб магазин (интерфейс, корзина и тп) + рабочие потоки внутри (роль менеджера по закупкам, менеджера по отправке и тп). Делал бы я ее классическим способом например JSF + Hibernate. Написал бы jsf странички, managed beans с логикой, DAO с вызовами в Hibernate и тд.
А в случае с  Groove-Grails я все то же самое генерирую значительно быстрее, потому что в принципе все эти классы стандартные. 
 То есть у меня все то,что я написал бы руками на JSF+Hibernate, будет внутри обертки Grails, и никаких ограничений в реализации бизнес логики я испытывать не буду из-за того, что пишу не все руками с нуля, а использую в обертке Grails. Правильно я понял? 
 А view уровень легко подключается на Vaadin.  

JSF - компонентно-ориентированный фреймворк. Либо страница, либо сервер будет хранить состояние. Это нужно учитывать, если будет много посетителей. Grails - action based.
На счет скорости. В жсф есть много готовых компонентов для интерфейса.
Бизнес логику нужно писать и там и там. Просто в грэйлс есть GORM, он кое-что сделает за тебя.
На мой взгляд жсф больше подходит для корпоративных приложений, админок и т.п.

А можно чуть объяснить - что значит Grails - action based? 

Это значит request based. Не хранит состояние. Разницу можно найти в интернете.

Для публичного сайта, по моему мнению, больше подходит grails или spring, чем jsf.

Там что нет такого scope как session, где можно сохранить состояние пользователя? А как же тогда интернет магазин с добавлением новых товаров в корзину будет работать? Получается это невозможно на Grails?

Да я бы вообще сказал, что JSF не пригоден для публичных сайтов.

Vaadin, кстати, то же.  Потому, если и реализовывать на нем View, то только в админке.  Но как показала практика - сделать с его помощью удобную (с точки зрения юзабилити) админку гораздо сложнее, чем средствами Grails. 


Про scope  ответил в соседней теме. 


Это сообщение отредактировал(а) Vasay - 16.10.2011, 03:55

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

Классно! Только начал рассматривать Vaadin - как раз maven dependencies  качает.
А почему на Vaadin нельзя view часть сайта сделать? И чем Grails его заменяет?

Я так определился уже сделать уровень view на Vaadin (это ж вроде более юзабельный интерфейс-обертка GWT),
а движок либо на Grails либо на Spring - Hibernate, если Grails сильно много накладывает ограничений и, честно говоря, пока что я не понял какие преимущества он дает, кроме готовых Dao типа getNameById. А разбираться с его ограничениями по структуре и другими нюансами (типа для каждого запроса своя страничка почему-то вроде delete.jsp) может занять немало времени. Если преимуществ особых нет, то собственно зачем. Никто так и не назвал реальные преимущества Grails. Может просто дело вкуса тогда.

oson


Потому что у Vaadin как и у других основанных на JS UI есть следующие проблемы:

- несоответствие контента URL, как следствие:
-- сайт не индексируется поисковыми системами 
-- пользователь не может сохранить страницу в закладки, или передать ссылку на страницу по почте или icq

- непривычное для пользователя поведения JS ссылок и навигации (например, неадекватная реакция на нажатие средней кнопки мышки (открыть в новом окне), неадекватное поведение кнопки "назад" браузера )

Кнопку назад лучше вообще заблокировать в проектах WorkFlow - потому что view должен отвечать состоянию системы.
Но я так понял тут вообще существует проблема (у всех основанных на JS UI) несоответствия "состояния движка" и  "отображения"?
То есть для управления рабочими процессами она по большому счету не подходит?

Что собственно взамен предлагает Grails? Есть у него что-то с rich interface? Или классические страницы только?

oson



Пользователи Вам за это спасибо не скажут.


К тому же, судя по описанию в Вашем первом посте, у вас WorkFlow не в том понимание которое применяется к фреймворкам (т.е. не последовательность экранов у одного пользователя). У Вас некий бизнес процесс (с передачей состояния между пользователями) который, полюбому, программировать руками.


п.с. так мы все-таки говорим о публичном сайте (интернет магазине) или о его админке с неким бизнес процессом? 

Публичный сайт, где покупатели тоже имеют роль в общем процессе. После того как покупатель сделал заказ (выполнил те шаги, которые можно делать в его роли), что-то меняется в состоянии для других ролей, которые начинают видеть это заказ - менеджеры всякие - и потом шаг за шагом обрабатывают его.
То есть и публичный сайт и админка - но в основе лежит именно управление рабочими потоками. То есть роль Покупатель сделал заказ и роль менеджер A увидел его, затем роль менеджер A выполнил 3 шага и перестал видеть этот заказ - зато видит роль менеджер B и делает свои шаги.