Grails vs Struts2

[borg]

We're planning a large new project, and we've engaged an external dev house to give us a hand. They're familiar and are recommending a Struts2/Spring/Hibernate technology stack.

We've been playing with Grails for a little while now, and have deployed a couple of small projects using it.

Can anyone share any thoughts on the major pitfalls or advantages with these two?

We'll be conducting some prototypes over the coming weeks, as we'll be maintaining this product for many years.

Just thought I'd ask the list as Spring/Struts is a well trodden path and I thought someone could share their experiences with both.

Cheers,
Dave

[interz]

We have migrated a struts1 app that also has some struts2 stuff in it. Search this list and the Grails JIRA issues for further info on what needed to be done to get it to work. If you have no dependancies on struts1 you might be ok. There are workarounds for struts1

borg wrote:

We're planning a large new project, and we've engaged an external dev house to give us a hand. They're familiar and are recommending a Struts2/Spring/Hibernate technology stack.

We've been playing with Grails for a little while now, and have deployed a couple of small projects using it.

Can anyone share any thoughts on the major pitfalls or advantages with these two?

We'll be conducting some prototypes over the coming weeks, as we'll be maintaining this product for many years.

Just thought I'd ask the list as Spring/Struts is a well trodden path and I thought someone could share their experiences with both.

Cheers,
Dave

[borg]

cheers, but this is a ground up dev project. no migration.

I'm keen to use grails, but I'd be interested to hear of any comparisons anyone would want to make.

Dave

On Thu, Mar 6, 2008 at 12:22 PM, interz <interz12@...> wrote:

We have migrated a struts1 app that also has some struts2 stuff in it. Search
this list and the Grails JIRA issues for further info on what needed to be
done to get it to work. If you have no dependancies on struts1 you might be
ok. There are workarounds for struts1

borg wrote:
>
> We're planning a large new project, and we've engaged an external dev
> house to give us a hand. They're familiar and are recommending a
> Struts2/Spring/Hibernate technology stack.
>
> We've been playing with Grails for a little while now, and have deployed a
> couple of small projects using it.
>
> Can anyone share any thoughts on the major pitfalls or advantages with
> these two?
>
> We'll be conducting some prototypes over the coming weeks, as we'll be
> maintaining this product for many years.
>
> Just thought I'd ask the list as Spring/Struts is a well trodden path and
> I thought someone could share their experiences with both.
>
> Cheers,
> Dave
>

--

View this message in context: http://www.nabble.com/Grails-vs-Struts2-tp15863547p15864478.html

Sent from the grails - user mailing list archive at Nabble.com.


---------------------------------------------------------------------
To unsubscribe from this list, please visit:

   http://xircles.codehaus.org/manage_email

[Alex Shneyderman]

>  We're planning a large new project, and we've engaged an external dev house
>  to give us a hand. They're familiar and are recommending a
>  Struts2/Spring/Hibernate technology stack.

That's one good stack to stick with :-)

>  We've been playing with Grails for a little while now, and have deployed a
>  couple of small projects using it.
>
>  Can anyone share any thoughts on the major pitfalls or advantages with these
>  two?
>
>  We'll be conducting some prototypes over the coming weeks, as we'll be
>  maintaining this product for many years.
>
>  Just thought I'd ask the list as Spring/Struts is a well trodden path and I
>  thought someone could share their experiences with both.

You would need to describe your project in a bit more details. I.e.
what portion of it is large? The back-end or the front-end?

I would definitely use Grails for the front-end. The controllers and
view technologies are in a fairly good shape. The taglibs are a great
feature. If you have any ajax plans the interaction between the
front-end and the back-end can not be made any simpler that with the
help of converters. You have groovy as your language on the back-end
to write the client-to-controller interactions.

S2 is quite Ok for the front-end as well, but it has verboseness of
Java and I think it is its main drawback. The taglibs are not as easy
to create. You can have your actions written in Groovy with S2 but
that is not a well known/supported case in their land. Ajax might not
be as simple to utilize with S2. S2 used to force Dojo on you - I
wonder if situation has changed and looking at Ian's book it does not
seem like it did. You could always do your own thing for the ajax
without the support of S2 but you would be lacking support/experience
of the community (which I think still matters)

Note, if you choose S2 over Grails it ain't that bad a choice. You
will have at least ono benefit over Grails: multiple view technologies
:-)

If Grails would be your choice the one thing I would definitely try to
avoid on a large-scale project is the use of GORM. It is ok for
prototyping but you can expect hick-ups if you use it in a way that is
not described in the manual. If the back-end logic is complicated
relying on GORM and service layer of Grails - IMO - is a bit
pre-mature. I would suggest you to write that in pure java with
Spring/Hibernate/AspectJ combo and hook it up to Grails' actions.

HTH,
Alex.

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email

[Graeme Rocher-2]

On Thu, Mar 6, 2008 at 6:45 AM, Alex Shneyderman
<a.shneyderman@...> wrote:

> >  We're planning a large new project, and we've engaged an external dev house
>  >  to give us a hand. They're familiar and are recommending a
>  >  Struts2/Spring/Hibernate technology stack.
>
>  That's one good stack to stick with :-)
>
>
>  >  We've been playing with Grails for a little while now, and have deployed a
>  >  couple of small projects using it.
>  >
>  >  Can anyone share any thoughts on the major pitfalls or advantages with these
>  >  two?
>  >
>  >  We'll be conducting some prototypes over the coming weeks, as we'll be
>  >  maintaining this product for many years.
>  >
>  >  Just thought I'd ask the list as Spring/Struts is a well trodden path and I
>  >  thought someone could share their experiences with both.
>
>  You would need to describe your project in a bit more details. I.e.
>  what portion of it is large? The back-end or the front-end?
>
>  I would definitely use Grails for the front-end. The controllers and
>  view technologies are in a fairly good shape. The taglibs are a great
>  feature. If you have any ajax plans the interaction between the
>  front-end and the back-end can not be made any simpler that with the
>  help of converters. You have groovy as your language on the back-end
>  to write the client-to-controller interactions.
>
>  S2 is quite Ok for the front-end as well, but it has verboseness of
>  Java and I think it is its main drawback. The taglibs are not as easy
>  to create. You can have your actions written in Groovy with S2 but
>  that is not a well known/supported case in their land. Ajax might not
>  be as simple to utilize with S2. S2 used to force Dojo on you - I
>  wonder if situation has changed and looking at Ian's book it does not
>  seem like it did. You could always do your own thing for the ajax
>  without the support of S2 but you would be lacking support/experience
>  of the community (which I think still matters)
>
>  Note, if you choose S2 over Grails it ain't that bad a choice. You
>  will have at least ono benefit over Grails: multiple view technologies
>  :-)

I don't believe that this can be described as an advantage over
Grails. There are already multiple view technologies you can use with
Grails (Flex, Wicket, GWT etc.)

>
>  If Grails would be your choice the one thing I would definitely try to
>  avoid on a large-scale project is the use of GORM. It is ok for
>  prototyping but you can expect hick-ups if you use it in a way that is
>  not described in the manual. If the back-end logic is complicated
>  relying on GORM and service layer of Grails - IMO - is a bit
>  pre-mature. I would suggest you to write that in pure java with
>  Spring/Hibernate/AspectJ combo and hook it up to Grails' actions.

Before making such a definitive statement Alex, could you explain why
you believe GORM is not a good choice? To me GORM eliminates the
boiler plate DAO code you would have to write anyway. Underneath its
plain Java and the performance difference is negligable. How exactly
is it pre-mature to use it?

If its the mapping, you can always use plain old Hibernate entities
and still get the advantage. Seriously, I'm really curious as to why
you believe this is the case

Cheers

>
>  HTH,
>  Alex.
>
>
>
>  ---------------------------------------------------------------------
>  To unsubscribe from this list, please visit:
>
>     http://xircles.codehaus.org/manage_email
>
>
>

--
Graeme Rocher
Grails Project Lead
G2One, Inc. Chief Technology Officer
http://www.g2one.com

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email

[felipenasc]

I have Struts applications running in production.
I have SpringMVC applications running in production (with the help of AppFuse).
I have Grails applications running in production.

They all use Spring + Hibernate.

For now on, I will always use Grails (until a new, better, framework appears).

If you can, stick with grails. It IS SpringMVC, Spring, Hibernate,
SiteMesh, Quartz, etc, etc. It is so agile to develop with. Is is
SIMPLE and POWERFUL. Why not Grails?

You can alwys write Java code with it, if you need. You can write your
own Hibernate mapping files, if you need (I have 2 applications with
custom hibernate xml mapping files, instead of GORM mapping).

Go for it

Cheers
Felipe

2008/3/6, Graeme Rocher <graeme@...>:

> On Thu, Mar 6, 2008 at 6:45 AM, Alex Shneyderman
>  <a.shneyderman@...> wrote:
>  > >  We're planning a large new project, and we've engaged an external dev house
>  >  >  to give us a hand. They're familiar and are recommending a
>  >  >  Struts2/Spring/Hibernate technology stack.
>  >
>  >  That's one good stack to stick with :-)
>  >
>  >
>  >  >  We've been playing with Grails for a little while now, and have deployed a
>  >  >  couple of small projects using it.
>  >  >
>  >  >  Can anyone share any thoughts on the major pitfalls or advantages with these
>  >  >  two?
>  >  >
>  >  >  We'll be conducting some prototypes over the coming weeks, as we'll be
>  >  >  maintaining this product for many years.
>  >  >
>  >  >  Just thought I'd ask the list as Spring/Struts is a well trodden path and I
>  >  >  thought someone could share their experiences with both.
>  >
>  >  You would need to describe your project in a bit more details. I.e.
>  >  what portion of it is large? The back-end or the front-end?
>  >
>  >  I would definitely use Grails for the front-end. The controllers and
>  >  view technologies are in a fairly good shape. The taglibs are a great
>  >  feature. If you have any ajax plans the interaction between the
>  >  front-end and the back-end can not be made any simpler that with the
>  >  help of converters. You have groovy as your language on the back-end
>  >  to write the client-to-controller interactions.
>  >
>  >  S2 is quite Ok for the front-end as well, but it has verboseness of
>  >  Java and I think it is its main drawback. The taglibs are not as easy
>  >  to create. You can have your actions written in Groovy with S2 but
>  >  that is not a well known/supported case in their land. Ajax might not
>  >  be as simple to utilize with S2. S2 used to force Dojo on you - I
>  >  wonder if situation has changed and looking at Ian's book it does not
>  >  seem like it did. You could always do your own thing for the ajax
>  >  without the support of S2 but you would be lacking support/experience
>  >  of the community (which I think still matters)
>  >
>  >  Note, if you choose S2 over Grails it ain't that bad a choice. You
>  >  will have at least ono benefit over Grails: multiple view technologies
>  >  :-)
>
>
> I don't believe that this can be described as an advantage over
>  Grails. There are already multiple view technologies you can use with
>  Grails (Flex, Wicket, GWT etc.)
>
>
>  >
>  >  If Grails would be your choice the one thing I would definitely try to
>  >  avoid on a large-scale project is the use of GORM. It is ok for
>  >  prototyping but you can expect hick-ups if you use it in a way that is
>  >  not described in the manual. If the back-end logic is complicated
>  >  relying on GORM and service layer of Grails - IMO - is a bit
>  >  pre-mature. I would suggest you to write that in pure java with
>  >  Spring/Hibernate/AspectJ combo and hook it up to Grails' actions.
>
>
> Before making such a definitive statement Alex, could you explain why
>  you believe GORM is not a good choice? To me GORM eliminates the
>  boiler plate DAO code you would have to write anyway. Underneath its
>  plain Java and the performance difference is negligable. How exactly
>  is it pre-mature to use it?
>
>  If its the mapping, you can always use plain old Hibernate entities
>  and still get the advantage. Seriously, I'm really curious as to why
>  you believe this is the case
>
>  Cheers
>
> >
>  >  HTH,
>  >  Alex.
>  >
>  >
>  >
>  >  ---------------------------------------------------------------------
>  >  To unsubscribe from this list, please visit:
>  >
>  >     http://xircles.codehaus.org/manage_email
>  >
>  >
>  >
>
>
>
>
> --
>  Graeme Rocher
>  Grails Project Lead
>  G2One, Inc. Chief Technology Officer
>  http://www.g2one.com
>
>
>  ---------------------------------------------------------------------
>  To unsubscribe from this list, please visit:
>
>     http://xircles.codehaus.org/manage_email
>
>
>

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email

[Daniel.Sun]

Graeme,

I think GORM is pre-mature too.

The reason is very obvious, please see the issue tracker(http://jira.codehaus.org/browse/GRAILS?report=com.atlassian.jira.plugin.system.project:roadmap-panel)

So many issues are about GORM, which is the reason why I don't apply GORM in the my projects.


Daniel

Graeme Rocher-2 wrote:

On Thu, Mar 6, 2008 at 6:45 AM, Alex Shneyderman
<[e-mail]> wrote:
> >  We're planning a large new project, and we've engaged an external dev house
>  >  to give us a hand. They're familiar and are recommending a
>  >  Struts2/Spring/Hibernate technology stack.
>
>  That's one good stack to stick with :-)
>
>
>  >  We've been playing with Grails for a little while now, and have deployed a
>  >  couple of small projects using it.
>  >
>  >  Can anyone share any thoughts on the major pitfalls or advantages with these
>  >  two?
>  >
>  >  We'll be conducting some prototypes over the coming weeks, as we'll be
>  >  maintaining this product for many years.
>  >
>  >  Just thought I'd ask the list as Spring/Struts is a well trodden path and I
>  >  thought someone could share their experiences with both.
>
>  You would need to describe your project in a bit more details. I.e.
>  what portion of it is large? The back-end or the front-end?
>
>  I would definitely use Grails for the front-end. The controllers and
>  view technologies are in a fairly good shape. The taglibs are a great
>  feature. If you have any ajax plans the interaction between the
>  front-end and the back-end can not be made any simpler that with the
>  help of converters. You have groovy as your language on the back-end
>  to write the client-to-controller interactions.
>
>  S2 is quite Ok for the front-end as well, but it has verboseness of
>  Java and I think it is its main drawback. The taglibs are not as easy
>  to create. You can have your actions written in Groovy with S2 but
>  that is not a well known/supported case in their land. Ajax might not
>  be as simple to utilize with S2. S2 used to force Dojo on you - I
>  wonder if situation has changed and looking at Ian's book it does not
>  seem like it did. You could always do your own thing for the ajax
>  without the support of S2 but you would be lacking support/experience
>  of the community (which I think still matters)
>
>  Note, if you choose S2 over Grails it ain't that bad a choice. You
>  will have at least ono benefit over Grails: multiple view technologies
>  :-)

I don't believe that this can be described as an advantage over
Grails. There are already multiple view technologies you can use with
Grails (Flex, Wicket, GWT etc.)

>
>  If Grails would be your choice the one thing I would definitely try to
>  avoid on a large-scale project is the use of GORM. It is ok for
>  prototyping but you can expect hick-ups if you use it in a way that is
>  not described in the manual. If the back-end logic is complicated
>  relying on GORM and service layer of Grails - IMO - is a bit
>  pre-mature. I would suggest you to write that in pure java with
>  Spring/Hibernate/AspectJ combo and hook it up to Grails' actions.

Before making such a definitive statement Alex, could you explain why
you believe GORM is not a good choice? To me GORM eliminates the
boiler plate DAO code you would have to write anyway. Underneath its
plain Java and the performance difference is negligable. How exactly
is it pre-mature to use it?

If its the mapping, you can always use plain old Hibernate entities
and still get the advantage. Seriously, I'm really curious as to why
you believe this is the case

Cheers
>
>  HTH,
>  Alex.
>
>
>
>  ---------------------------------------------------------------------
>  To unsubscribe from this list, please visit:
>
>     http://xircles.codehaus.org/manage_email
>
>
>



--
Graeme Rocher
Grails Project Lead
G2One, Inc. Chief Technology Officer
http://www.g2one.com

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email

[Graeme Rocher-2]

Sure and there are 1185 issues related to hibernate open on their
JIRA: http://opensource.atlassian.com/projects/hibernate/secure/IssueNavigator.jspa?reset=true&mode=hide&pid=10031&resolution=-1&sorter/field=updated&sorter/order=DESC

I guess its not stable either ;-)

JIRA issues is a very poor metric for tracking stability as it has
very little to do with the quality of the software.

The issues you run into with GORM can be divided into to categories

a) I'm trying to map to some legacy DB and I can't do it because GORM
doesn't support it
b) There is something in the dynamic query language / criteria that is buggy

With a) you can and always have been able to fall back to traditional
hibernate xml or annotations for such issues
For b) there are very little if none related to this part of GORM in
the JIRA issue list and this is where the real value of GORM lies

So in conclusion if you have a greenfield project you're likely to
suffer less with a) if you don't use GORM mappings

Either way you are better off using GORM to remove the boilerplate.

Cheers

On Thu, Mar 6, 2008 at 3:20 PM, Daniel.Sun <realbluesun@...> wrote:

>
>  Graeme,
>
>  I think GORM is pre-mature too.
>
>  The reason is very obvious, please see the issue
>  tracker(http://jira.codehaus.org/browse/GRAILS?report=com.atlassian.jira.plugin.system.project:roadmap-panel)
>
>  So many issues are about GORM, which is the reason why I don't apply GORM in
>  the my projects.
>
>
>  Daniel
>
>
>
>
>  Graeme Rocher-2 wrote:
>  >
>  > On Thu, Mar 6, 2008 at 6:45 AM, Alex Shneyderman
>  > <a.shneyderman@...> wrote:
>  >> >  We're planning a large new project, and we've engaged an external dev
>  >> house
>  >>  >  to give us a hand. They're familiar and are recommending a
>  >>  >  Struts2/Spring/Hibernate technology stack.
>  >>
>  >>  That's one good stack to stick with :-)
>  >>
>  >>
>  >>  >  We've been playing with Grails for a little while now, and have
>  >> deployed a
>  >>  >  couple of small projects using it.
>  >>  >
>  >>  >  Can anyone share any thoughts on the major pitfalls or advantages
>  >> with these
>  >>  >  two?
>  >>  >
>  >>  >  We'll be conducting some prototypes over the coming weeks, as we'll
>  >> be
>  >>  >  maintaining this product for many years.
>  >>  >
>  >>  >  Just thought I'd ask the list as Spring/Struts is a well trodden path
>  >> and I
>  >>  >  thought someone could share their experiences with both.
>  >>
>  >>  You would need to describe your project in a bit more details. I.e.
>  >>  what portion of it is large? The back-end or the front-end?
>  >>
>  >>  I would definitely use Grails for the front-end. The controllers and
>  >>  view technologies are in a fairly good shape. The taglibs are a great
>  >>  feature. If you have any ajax plans the interaction between the
>  >>  front-end and the back-end can not be made any simpler that with the
>  >>  help of converters. You have groovy as your language on the back-end
>  >>  to write the client-to-controller interactions.
>  >>
>  >>  S2 is quite Ok for the front-end as well, but it has verboseness of
>  >>  Java and I think it is its main drawback. The taglibs are not as easy
>  >>  to create. You can have your actions written in Groovy with S2 but
>  >>  that is not a well known/supported case in their land. Ajax might not
>  >>  be as simple to utilize with S2. S2 used to force Dojo on you - I
>  >>  wonder if situation has changed and looking at Ian's book it does not
>  >>  seem like it did. You could always do your own thing for the ajax
>  >>  without the support of S2 but you would be lacking support/experience
>  >>  of the community (which I think still matters)
>  >>
>  >>  Note, if you choose S2 over Grails it ain't that bad a choice. You
>  >>  will have at least ono benefit over Grails: multiple view technologies
>  >>  :-)
>  >
>  > I don't believe that this can be described as an advantage over
>  > Grails. There are already multiple view technologies you can use with
>  > Grails (Flex, Wicket, GWT etc.)
>  >
>  >>
>  >>  If Grails would be your choice the one thing I would definitely try to
>  >>  avoid on a large-scale project is the use of GORM. It is ok for
>  >>  prototyping but you can expect hick-ups if you use it in a way that is
>  >>  not described in the manual. If the back-end logic is complicated
>  >>  relying on GORM and service layer of Grails - IMO - is a bit
>  >>  pre-mature. I would suggest you to write that in pure java with
>  >>  Spring/Hibernate/AspectJ combo and hook it up to Grails' actions.
>  >
>  > Before making such a definitive statement Alex, could you explain why
>  > you believe GORM is not a good choice? To me GORM eliminates the
>  > boiler plate DAO code you would have to write anyway. Underneath its
>  > plain Java and the performance difference is negligable. How exactly
>  > is it pre-mature to use it?
>  >
>  > If its the mapping, you can always use plain old Hibernate entities
>  > and still get the advantage. Seriously, I'm really curious as to why
>  > you believe this is the case
>  >
>  > Cheers
>  >>
>  >>  HTH,
>  >>  Alex.
>  >>
>  >>
>  >>
>  >>  ---------------------------------------------------------------------
>  >>  To unsubscribe from this list, please visit:
>  >>
>  >>     http://xircles.codehaus.org/manage_email
>  >>
>  >>
>  >>
>  >
>  >
>  >
>  > --
>  > Graeme Rocher
>  > Grails Project Lead
>  > G2One, Inc. Chief Technology Officer
>  > http://www.g2one.com
>  >
>  > ---------------------------------------------------------------------
>  > To unsubscribe from this list, please visit:
>  >
>  >     http://xircles.codehaus.org/manage_email
>  >
>  >
>  >
>  >
>
>  --
>  View this message in context: http://www.nabble.com/Grails-vs-Struts2-tp15863547p15873576.html
>
> Sent from the grails - user mailing list archive at Nabble.com.
>
>
>  ---------------------------------------------------------------------
>
>
> To unsubscribe from this list, please visit:
>
>     http://xircles.codehaus.org/manage_email
>
>
>

--
Graeme Rocher
Grails Project Lead
G2One, Inc. Chief Technology Officer
http://www.g2one.com

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email

[Richard L. Burton III]

I've worked with both Grails and Struts 2 and I honestly enjoy them both.

If I were forced to pick on over the other, my choice would be Grails for the following reasons.


1. Seamless integration with Hibernate by way of GORM. GORM still has some work to do, but it's pretty mature in regards to the feature set. From my use of GORM, I haven’t encountered any issues, then again I haven't tried anything complex.
2. Seamless integration with Spring. All services are injected which I believe should be a core of any framework :) I still wish I could modify a service and not restart my application. <wink>
3. Seamless integration with SiteMesh – Its nice to have theme support out of the box!
4. Validation – This is something I strongly belong Grails got right where most fail miserably. It's very elegant!
5. Builds – No need to write a build script! Read http://graemerocher.blogspot.com/2008/01/why-grails-doesnt-use-maven.html 
6. Easy custom tags – Creating tags are crazy simple! No interfaces, no TLD, no sweat!


Struts has a lot of nice features as well. But in terms of productive, Grails puts Web Development with Java in the rankings of Rails. Not only that, but you can leverage existing Java code and also leverage the enterprise solutions from within Grails.

There's still more work on the documentation for both projects, but it's really getting there.

I strongly recommend you trying both of them and judging for yourself which is best for you. Both groups of developers are really smart.

Best Regards,
Richard L. Burton III

borg wrote:

We're planning a large new project, and we've engaged an external dev house to give us a hand. They're familiar and are recommending a Struts2/Spring/Hibernate technology stack.

We've been playing with Grails for a little while now, and have deployed a couple of small projects using it.

Can anyone share any thoughts on the major pitfalls or advantages with these two?

We'll be conducting some prototypes over the coming weeks, as we'll be maintaining this product for many years.

Just thought I'd ask the list as Spring/Struts is a well trodden path and I thought someone could share their experiences with both.

Cheers,
Dave

[cilquirm]

We just recently launched a major initiative using S2/JPA/Spring, and internally worked on grails  and S2/JPA/Guice projects.

We've ( or at least I ) have been tracking Grails pretty closely, because I can't imagine it not being a consideration for new projects.  You'd be doing your happiness and your product timeline a huge disservice ;-).

We learned a lot during this time, and one of the considerations that you have to make is that Grails is still another language for some of the key layers.  It's not that far different from Java, but our thought process was that if we're going to use a new language, we want to use it right, and we just knew Java better.   It should also be mentioned that, for some, the word "dynamic language" has people reaching for their profilers and load testers.

The other big consideration is that Grails, because it specifies a convention, picks out a number of technologies for you, and that decision has been made.  Granted, some of those decisions are ones that  tons of people make the same way every single day ( i.e. choosing Hibernate, Spring, and Quartz ), but  if you want to do something different, it's very hard to do so, currently, without more intimate knowledge of the system.

We had decided on using JPA and were considering Guice as a possibility ( though we went with Spring ) , and therefore the choice factor played heavily into it as well.

Grails has a lot going for it.  I can't help but praise its power, simplicity, and as many have found, what a joy it is to actually code in Groovy.  

But, we also discovered that modern web frameworks like S2 have great facilities that make a lot of things simpler.  In our projects, we ended up using the s2 codebehind plugin, which automaps actions to views, and  crank-crud, which takes a lot of the work of creating a dao layer.   In another project, I used the SmartURLs plugin, and warp-persist/guice and a simple library called jpacriteria for similar functionality.  

In the end, I don't think you can go wrong with Grails, but I have still had an enoyable time working in S2.

borg wrote:

cheers, but this is a ground up dev project. no migration.

I'm keen to use grails, but I'd be interested to hear of any comparisons
anyone would want to make.

Dave

[Peter Ledbrook]

>  We learned a lot during this time, and one of the considerations that you
>  have to make is that Grails is still another language for some of the key
>  layers.  It's not that far different from Java, but our thought process was
>  that if we're going to use a new language, we want to use it right, and we
>  just knew Java better.

I think this is an important point. Groovy is not Java. It looks a lot
like Java and integrates well with it, but it's fundamentally a
dynamic language. Some people take to it like a duck to water, but
others struggle. If time is tight and you have a bunch of Java
developers, then sticking to Java is less risky. However, if you have
time to get a team adjusted to Groovy and Grails, then the
productivity boost can be well worth the investment :)

Cheers,

Peter

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email

[Robert Leland-3]

<disclaimer> I haven't used S2 or Grails, but have used S1 and have been
following S2 mailing list as well a Grails list.</disclaimer>
I am going to talk about Struts since I know nothing about Grails.

Struts 2.0 while starting off with a good base in Webwork has been
learning lessons from Rails and
moving to convention over configuration. The S2.0 branch is of GA
quality which means General Availability.

One thing you should know if that Struts doesn't issue Alpha,Beta
releases. Each releases quality is voted on
then marked Alpha,Beta, GA based on weather any and what types of bugs
are present.
So you see 2.0.10, 2.0.11, and 2.0.11.1 as the latest releases.

The Struts 2.1 branch has  improved  even more in the Area of convention.
However a 2.1.1 release has not occurred yet but one is hopefully close.
In the Open Source world close could
mean 2 weeks, 2 months or 6 months, only the Struts committers would
know this.
Then it usually it takes a few release before the a quality of GA is
obtained. So if your project has a very short time frame
the 2.1 branch might not be appropriate.

One thing that often gets overlooked is how easy is the framework to
Unit/Mock/Regression test, and what is your testing requirements.
I'll strongly recommend checking this out if you will be building out
a big set of tests. I don't have a feel for which is easiest to test.


-Rob


--
Robert Leland                Robert@...
------------------------------------------
Java, J2EE, Struts, Web Application Development

804 N. Kenmore Street +01-703-525-3580
Arlington VA 22201


---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email

[Graeme Rocher-2]

On Thu, Mar 6, 2008 at 5:48 PM, Peter Ledbrook <peter@...> wrote:

> >  We learned a lot during this time, and one of the considerations that you
>  >  have to make is that Grails is still another language for some of the key
>  >  layers.  It's not that far different from Java, but our thought process was
>  >  that if we're going to use a new language, we want to use it right, and we
>  >  just knew Java better.
>
>  I think this is an important point. Groovy is not Java. It looks a lot
>  like Java and integrates well with it, but it's fundamentally a
>  dynamic language. Some people take to it like a duck to water, but
>  others struggle. If time is tight and you have a bunch of Java
>  developers, then sticking to Java is less risky. However, if you have
>  time to get a team adjusted to Groovy and Grails, then the
>  productivity boost can be well worth the investment :)

Yes this I agree with, there is certainly a learning curve and the
transition won't necessarily be seamless.
Having said that, out of the dynamic languages Groovy does provide the
shortest learning curve and will feel more natural to Java developers.

Key point about dynamic languages - don't expect the compiler to save you ;-)

Cheers

>
>  Cheers,
>
>  Peter
>
>
>
>  ---------------------------------------------------------------------
>  To unsubscribe from this list, please visit:
>
>     http://xircles.codehaus.org/manage_email
>
>
>

--
Graeme Rocher
Grails Project Lead
G2One, Inc. Chief Technology Officer
http://www.g2one.com

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email

[Richard L. Burton III]

Awesome, I'm going to disagree with the author of Grails!

The learning curve for Grails is pretty low if you ask me. Honestly, it took me about 20 minutes to learn how to use Grails to create a version of JRoller (Limited to Login, Post, Edit, Delete, Comments, and Profiles) in a matter of an hour (Including learning).

If you have any background in Rails (My background is really limited to research and playing with it), then your learning curve is going to be very low in terms of understanding the convention used in Grails. Groovy is really a super set of Java, so you're not forced to use every feature in Groovy. With that being said, the things like Closures and other items are easy to grasph.

I recommend anyone who wants to learn Grails to view the screen casts. It's a great way to start learning Grails and also picking up "Groovy in Action" and "The definitive guide to Grails". Two great books in getting started with Groovy and Grails.

Happy coding!

Best regards,
Richard L. Burton III

Graeme Rocher-2 wrote:

On Thu, Mar 6, 2008 at 5:48 PM, Peter Ledbrook <[e-mail]> wrote:
> >  We learned a lot during this time, and one of the considerations that you
>  >  have to make is that Grails is still another language for some of the key
>  >  layers.  It's not that far different from Java, but our thought process was
>  >  that if we're going to use a new language, we want to use it right, and we
>  >  just knew Java better.
>
>  I think this is an important point. Groovy is not Java. It looks a lot
>  like Java and integrates well with it, but it's fundamentally a
>  dynamic language. Some people take to it like a duck to water, but
>  others struggle. If time is tight and you have a bunch of Java
>  developers, then sticking to Java is less risky. However, if you have
>  time to get a team adjusted to Groovy and Grails, then the
>  productivity boost can be well worth the investment :)

Yes this I agree with, there is certainly a learning curve and the
transition won't necessarily be seamless.
Having said that, out of the dynamic languages Groovy does provide the
shortest learning curve and will feel more natural to Java developers.

Key point about dynamic languages - don't expect the compiler to save you ;-)

Cheers
>
>  Cheers,
>
>  Peter
>
>
>
>  ---------------------------------------------------------------------
>  To unsubscribe from this list, please visit:
>
>     http://xircles.codehaus.org/manage_email
>
>
>



--
Graeme Rocher
Grails Project Lead
G2One, Inc. Chief Technology Officer
http://www.g2one.com

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email

[dahernan]

I agree with you Richard, the learning curve for me it was very low.

Ok, had experience with all technologies around grails (spring,
sitemesh, web flow, etc) but for a new developer I think it will be
less than if starts directly with this technologies (spring, sitemesh,
web flow), and this is a fantastic point for Grails.

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email

[Darryl Pentz]

I'm really pleased this discussion started, and it's been educational reading the responses. I'll chip in with my $0.02 as well.

I too have been at that crossroads of "should I use Grails, or should I use (framework X)". In the end I used both on the same project.

The reason is that one of the components in this project is a management application, that manages the server - not like management beans - more like users, groups, upload this and that etc. The user load will never be too high, probably max 20 administrators at any installation.

The other component is a server application that communicates with N devices on a network. So it could be 10, it could be 1000, depending on where this product is installed. For this reason, I opted to go with a regular Java servlet-based setup (it's not an MVC application, no UI involved) using Spring + Hibernate.

My fear with Grails is currently its dynamic language feature. Both Graeme and Guillaume confess that Groovy can still do with a lot of optimization work and that their focus has been on getting the Grails Groovy code, and for Guillaume, Groovy itself, bedded down first before they focus on performance. Fair enough, and it's the right way to go about it. But that layer of unoptimized dynamic code makes me nervous about running high load applications. So for that reason I steered clear of Grails for the server component. It may all be just that - perception - but as the cliche goes, perception is reality, so there you have it. :-)

I'd be thrilled if others chimed in with how well Grails works for them with a gazillion concurrent connections and transactions and what have you. It'd certainly make my life easier.

Apart from that, I would also find using Grails something that I'd need team or dept buy-in from first. It's a risk to your company if you develop something in Grails and then up sticks and leave, with some other poor Grails-illiterate sod has to take over where you left off. But certainly that's a fight worth taking on - convincing others of its merits. I also found the learning curve very quick, and the uptake on Groovy was quick too because it had all the features that I'd been longing for in Java e.g. closures.

That's my $0.02 for what it's worth. :-) Great discussion though. If you haven't already chimed in yet, and you have your own Grails vs X experiences to share, please do.

Regards,
Darryl Pentz



      ____________________________________________________________________________________
Be a better friend, newshound, and
know-it-all with Yahoo! Mobile.  Try it now.  http://mobile.yahoo.com/;_ylt=Ahu06i62sR8HDtDypao8Wcj9tAcJ 


---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email

[Matt Lachman]

I figured I'd throw in my experiences as well.

I started out with Java web development about four years ago using
Struts 1.x.  The project we were working on was an internal website for
running data processing workflows and had about 50 users or so (don't
hold me to that - it's my best guess).  I thought Struts was a pretty
cool framework at the time.

I'm now using Grails for another internal website with about 20 users
max (I'm more certain about that number ;).  It has me saying, "why
couldn't I have had this four years ago!"  It brings together so many of
the established technologies that I've wanted to use but never had the
time to learn individually (Spring, Hibernate, Ajax).  It also brings
together many technologies I've never heard of before.  And Grails does
it in a way that makes them easy to use IMHO (compared to wiring
everything together manually with Struts).

Also, Groovy is awesome.  In my case, with about 20 internal customers,
performance isn't *that* big of a deal so I'm not really worried about
the dynamic nature of the language.  I also love that it's essentially
Java++ - I can reuse all of my old Java syntax and know that it'll work.
Where I have time, I can upgrade to all of the cool Groovy features.  My
favorite thing though is that it cuts out nearly all of the boilerplate
code I've had to write before.

I'm pretty sold on Grails.  :)

Matt

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email

[fernando.takai]

Matthew.Lachman@... wrote:

> I figured I'd throw in my experiences as well.
>
> I started out with Java web development about four years ago using
> Struts 1.x.  The project we were working on was an internal website for
> running data processing workflows and had about 50 users or so (don't
> hold me to that - it's my best guess).  I thought Struts was a pretty
> cool framework at the time.
>
> I'm now using Grails for another internal website with about 20 users
> max (I'm more certain about that number ;).  It has me saying, "why
> couldn't I have had this four years ago!"  It brings together so many of
> the established technologies that I've wanted to use but never had the
> time to learn individually (Spring, Hibernate, Ajax).  It also brings
> together many technologies I've never heard of before.  And Grails does
> it in a way that makes them easy to use IMHO (compared to wiring
> everything together manually with Struts).
>
> Also, Groovy is awesome.  In my case, with about 20 internal customers,
> performance isn't *that* big of a deal so I'm not really worried about
> the dynamic nature of the language.  I also love that it's essentially
> Java++ - I can reuse all of my old Java syntax and know that it'll work.
> Where I have time, I can upgrade to all of the cool Groovy features.  My
> favorite thing though is that it cuts out nearly all of the boilerplate
> code I've had to write before.
>
> I'm pretty sold on Grails.  :)
>
> Matt
>
> ---------------------------------------------------------------------
> To unsubscribe from this list, please visit:
>
>     http://xircles.codehaus.org/manage_email
>
>
>  

mmm... everybody is saying that groovy is a dynamic language and etc and maybe, the performance will be not so good. But, if make a war, will it be dynamic or compiled? -- logically, compiled -- so -- the performance problem is not about be dynamic, it's about performatic code.

my $0.01:

i've been around web development for about two years and a half -- working with jsp/servlets, spring mvc,  and, more recently jsf.

all of these technologies are wonderful -- specially for a guy like me, that don't really know how to build a beautiful ui (specially jsf).

but, when i started using grails, i felt in love!

the learning curve was almost zero (for me) specially because i've already played around with turbo gears (python framework)

gorm is a wonderful way of hibernate encapsulation, and the spring support made everything prettier.

if had to choose between any web-framwork and grails, i'd choose grails -- cause, at the end of the day it's java!

cheers!


--
Fernando "Takai"
http://fernandotakai.wordpress.com
http://flickr.com/supeertakai
http://twitter.com/fernando_takai


---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email

[Darryl Pentz]

I'm really pressed for time otherwise I'd be happy to do it, but if anyone does have the time, these would be great as 'Developer Testimonials' on the Grails site - for other developers to read who are considering Grails as an option to takeup and learn and use in their day to day work.

- DP




      ____________________________________________________________________________________
Looking for last minute shopping deals?  
Find them fast with Yahoo! Search.  http://tools.search.yahoo.com/newsearch/category.php?category=shopping

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email

[Matt Lachman]

Added mine here: http://docs.codehaus.org/display/GRAILS/Testimonials

Matt

-----Original Message-----
From: Darryl Pentz [mailto:djpentz@...]
Sent: Friday, March 07, 2008 10:50 AM
To: user@...
Subject: Re: [grails-user] Grails vs Struts2

I'm really pressed for time otherwise I'd be happy to do it, but if
anyone does have the time, these would be great as 'Developer
Testimonials' on the Grails site - for other developers to read who are
considering Grails as an option to takeup and learn and use in their day
to day work.

- DP

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email