Версия для печати темы
Нажмите сюда для просмотра этой темы в оригинальном формате
Форум программистов > Java: Groovy & Grails > Что выбрать?


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

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

Автор: Stolzen 6.10.2011, 09:47
Цитата(oson @  6.10.2011,  10:35 Найти цитируемый пост)
 то есть надо использовать и другие Springi типа SpringMVC и тп? 

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

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

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

Автор: Stolzen 6.10.2011, 15:22
Нет, не джава, JVM-based язык. Сам лично GWT не подключал, но http://grails.org/plugin/gwt, что можно. А вообще я пытался на груви писать для GWT, правда только серверную часть - вполне сносно. 

Автор: oson 6.10.2011, 18:38
То есть на базе Spring сделали новый язык?

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

Автор: Vasay 10.10.2011, 01:21
Цитата(oson @  6.10.2011,  15:08 Найти цитируемый пост)
Не совсем понял. Так это уже не Java? А если я захочу потом на view уровне подключить GWT например - то уже не получится? То есть буду жестко привязан уже к Grails,  к тому что предлагает именно он и не смогу даже при необходимости SpringMVC подключить?


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

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

Добавлено через 2 минуты и 58 секунд
Цитата(emmanuil @  7.10.2011,  14:52 Найти цитируемый пост)
Нет, не на базе. http://ru.wikipedia.org/wiki/Groovy


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

 объектно-ориентированный язык программирования разработанный для платформы Java как альтернатива языку Java с возможностями Python, Ruby и Smalltalk.


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

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

Автор: emmanuil 11.10.2011, 09:55
Не надо так категорично. smile
Альтернатива это ведь не замена.

Автор: oson 15.10.2011, 20:44
Цитата(Vasay @ 10.10.2011,  01:21)
GWT подключить получится. (сам, правда не подключал - подключал Vaadin, который в свою очередь основан на GWT)

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

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

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

Автор: oson 15.10.2011, 21:21
А можно чуть объяснить - что значит Grails - action based? 

Автор: emmanuil 15.10.2011, 21:29
Это значит request based. Не хранит состояние. Разницу можно найти в интернете.

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

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

Автор: Vasay 16.10.2011, 03:53
Цитата(emmanuil @  15.10.2011,  21:29 Найти цитируемый пост)
Для публичного сайта, по моему мнению, больше подходит grails или spring, чем jsf.


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

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


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

Автор: emmanuil 16.10.2011, 07:08
Цитата(Vasay @  16.10.2011,  01:53 Найти цитируемый пост)
Да я бы вообще сказал, что JSF не пригоден для публичных сайтов.

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

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

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

Автор: Vasay 16.10.2011, 14:12
oson
Цитата

А почему на Vaadin нельзя view часть сайта сделать?


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

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

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

Автор: oson 16.10.2011, 14:45
Цитата(Vasay @ 16.10.2011,  14:12)
oson
Цитата

А почему на Vaadin нельзя view часть сайта сделать?


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

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

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

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

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

Автор: Vasay 16.10.2011, 15:48
oson

Цитата

Кнопку назад лучше вообще заблокировать в проектах WorkFlow - потому что view должен отвечать состоянию системы.


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


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


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

Автор: oson 16.10.2011, 16:11
Цитата(Vasay @  16.10.2011,  15:48 Найти цитируемый пост)
п.с. так мы все-таки говорим о публичном сайте (интернет магазине) или о его админке с неким бизнес процессом?  


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

Powered by Invision Power Board (http://www.invisionboard.com)
© Invision Power Services (http://www.invisionpower.com)