Greenfield development: Tapestry or Grails for Groovy dev?

classic Classic list List threaded Threaded
11 messages Options
Reply | Threaded
Open this post in threaded view
|

Greenfield development: Tapestry or Grails for Groovy dev?

scrotty
I am about to create a brand new website. I plan on using Groovy for my JVM language (just an arbitrary constraint I imposed on myself as part of the polyglot experience) and would like to give my users the niceties of AJAX on the front end. Everything else: DB, ORM, Web framework, etc. are wide open.

I am not new to development in general nor web development in particular. I have development experience in all the layers typically used in a web application (from browser to DB). I am looking for technologies that will allow me to create and maintain a straight-forward web application while minimizing the "gotchas" that naturally occur when gluing each layer together.

For web framework I've narrowed my candidates down to Grails and Tapestry and am leaning toward Tapestry. But it's hard for me to ignore the Groovy synergy in Grails.

Does anyone have recommendations (especially - but not exclusively - if you've used Groovy with Tapestry) on which field I should plant my seeds in?

Thank You!
Sean
Reply | Threaded
Open this post in threaded view
|

Re: Greenfield development: Tapestry or Grails for Groovy dev?

lprimak
I am using groovy and tapestry with great success in our projects. We rejected
Grails in our web framework bake off couple of years ago mostly due to
Inability of web designers to work with it.

On Oct 9, 2012, at 3:39 PM, scrotty <[hidden email]> wrote:

> I am about to create a brand new website. I plan on using Groovy for my JVM
> language (just an arbitrary constraint I imposed on myself as part of the
> polyglot experience) and would like to give my users the niceties of AJAX on
> the front end. Everything else: DB, ORM, Web framework, etc. are wide open.
>
> I am not new to development in general nor web development in particular. I
> have development experience in all the layers typically used in a web
> application (from browser to DB). I am looking for technologies that will
> allow me to create and maintain a straight-forward web application while
> minimizing the "gotchas" that naturally occur when gluing each layer
> together.
>
> For web framework I've narrowed my candidates down to Grails and Tapestry
> and am leaning toward Tapestry. But it's hard for me to ignore the Groovy
> synergy in Grails.
>
> Does anyone have recommendations (especially - but not exclusively - if
> you've used Groovy with Tapestry) on which field I should plant my seeds in?
>
> Thank You!
> Sean
>
>
>
> --
> View this message in context: http://tapestry.1045711.n5.nabble.com/Greenfield-development-Tapestry-or-Grails-for-Groovy-dev-tp5716732.html
> Sent from the Tapestry - User mailing list archive at Nabble.com.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Greenfield development: Tapestry or Grails for Groovy dev?

Thiago H de Paula Figueiredo
In reply to this post by scrotty
I haven't used Groovy myself, but it seems Tapestry and it work very well  
for a long time. I've found a post by Howard Lewis Ship about this  
combination in Tapestry 5.0.12, which was an alpha version, all that in  
2008:  
http://tapestryjava.blogspot.com.br/2008/06/tapestry-with-groovy.html.  
Tapestry doesn't case about the language you use, as long as it generates  
.class files and you put them in the right places. Some people has used  
Tapestry with Scala too.

On Tue, 09 Oct 2012 16:39:16 -0300, scrotty <[hidden email]> wrote:

> I am about to create a brand new website. I plan on using Groovy for my  
> JVM
> language (just an arbitrary constraint I imposed on myself as part of the
> polyglot experience) and would like to give my users the niceties of  
> AJAX on
> the front end. Everything else: DB, ORM, Web framework, etc. are wide  
> open.
>
> I am not new to development in general nor web development in  
> particular. I
> have development experience in all the layers typically used in a web
> application (from browser to DB). I am looking for technologies that will
> allow me to create and maintain a straight-forward web application while
> minimizing the "gotchas" that naturally occur when gluing each layer
> together.
>
> For web framework I've narrowed my candidates down to Grails and Tapestry
> and am leaning toward Tapestry. But it's hard for me to ignore the Groovy
> synergy in Grails.
>
> Does anyone have recommendations (especially - but not exclusively - if
> you've used Groovy with Tapestry) on which field I should plant my seeds  
> in?
>
> Thank You!
> Sean
>
>
>
> --
> View this message in context:  
> http://tapestry.1045711.n5.nabble.com/Greenfield-development-Tapestry-or-Grails-for-Groovy-dev-tp5716732.html
> Sent from the Tapestry - User mailing list archive at Nabble.com.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>


--
Thiago H. de Paula Figueiredo

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Greenfield development: Tapestry or Grails for Groovy dev?

Alex Kotchnev-2
In the past five years, I worked on a number of greenfield projects. In
three out of four, we ended up choosing Grails - it is very hard to deny
the market & mindshare , the expansive documentation, the big name company
behind the project, the large community, a massive number of plugins (for
pretty much anything that you'd want), the end-to-end stack (so, you don't
have to choose your ORM, DI, etc) and the ease of getting started with a
Grails project.

However, after working on a couple of these Grails projects for a few
years, the latest project I got involved with , I chose Tapestry. In some
cases, I've missed some of the niceties that Grails brings out of the box,
but without too much effort I've been able to replicate them fairly easily.

The biggest reasons for picking Tapestry over Grails on this latest project
have been:
1. The inability to aggressively refactor your code - the dynamic nature of
the language is nice when you want to knock something out quickly, and
saves you a few lines of code here and there. However, after the codebase
gets to a certain size, the inability to reliably refactor the codebase
made the codebase difficult to evolve. Sure, IntelliJ & NetBeans has some
support for refactorings in Groovy; however, it is not even close to the
level of depth and ease of what you get with Java. I love Groovy to death,
have been using it for many years (since it was in jsr-1 version) but ...
the tool support is just not there yet (and likely will never be) and for a
team of developers Java just ends up being a better choice (at least in the
context of my team)

2. The importance of Tapestry components cannot be overstated. In a fairly
modern web app, the functionality of each page depends on a bunch of
markup, some CSS from a stylesheet, and some javascript from a javascript
file. Tapestry makes putting everything together and using the results
extremely easy and logical. In the late days of the last Grails project I
was involved in, it was a massive PITA to build a page that really should
have looked like 'that other one' - even when you used tag libraries to
encapsulate the markup generation, you still had to hunt down all the css
and js files that needed to be there.

On the first issue, if you will be using Groovy for your pages, you will be
in the same boat as Grails. Personally, I wouldn't recommend it - Tapestry
already pushes the envelope on Java quite a bit, so your Java code ends up
being very short and sweet already. In the past, I had attempted to use
Scala in a tapestry app, and ended up having to just deal w/ some of the
mismatches between the language and the framework and my pages ended up
looking up like the same old java pages I would have had but with a
different syntax.

On the second issue, there is the grails resources plugin that tries to
pull resources kinda like Tapestry, but using it requires this artificial
separation into resource bundles which seems to be a PITA and somewhat mind
bending.

On the abundance of Grails plugins - after using a bunch for the projects I
was working on, it turned out that many were not well maintained so we had
to take over and maintain them ourselves. Sometimes, they're a good
starting point, but in the end ended up less of a factor than I initially
thought.

I originally very much enjoyed the Grails build system (running on top of
Gradle); however, with a pretty simple project setup, Maven seems to be
just as straightforward. If you wanted Gradle, you could use that for your
Tapestry app, and be on-par w/ Grails.

On the latest project that I chose Tapestry for , I have been very happy
with my choice. On a few occasions I've run into some frustrations (e.g.
for rendering emails, I ended up having to use Freemarker, whereas with
Grails the template rendering for emails comes for 'free' ; I had to build
my own equivalent of the Grails "console" plugin where you can run Groovy
commands inside of your running application); however, in all cases, the
solution has turned out to be more elegant than I had expected (albeit, it
required deeper tweaks in the framework than I had expected).

Cheers,

Alex Kochnev

On Tue, Oct 9, 2012 at 4:17 PM, Thiago H de Paula Figueiredo <
[hidden email]> wrote:

> I haven't used Groovy myself, but it seems Tapestry and it work very well
> for a long time. I've found a post by Howard Lewis Ship about this
> combination in Tapestry 5.0.12, which was an alpha version, all that in
> 2008: http://tapestryjava.blogspot.**com.br/2008/06/tapestry-with-**
> groovy.html<http://tapestryjava.blogspot.com.br/2008/06/tapestry-with-groovy.html>.
> Tapestry doesn't case about the language you use, as long as it generates
> .class files and you put them in the right places. Some people has used
> Tapestry with Scala too.
>
>
> On Tue, 09 Oct 2012 16:39:16 -0300, scrotty <[hidden email]> wrote:
>
>  I am about to create a brand new website. I plan on using Groovy for my
>> JVM
>> language (just an arbitrary constraint I imposed on myself as part of the
>> polyglot experience) and would like to give my users the niceties of AJAX
>> on
>> the front end. Everything else: DB, ORM, Web framework, etc. are wide
>> open.
>>
>> I am not new to development in general nor web development in particular.
>> I
>> have development experience in all the layers typically used in a web
>> application (from browser to DB). I am looking for technologies that will
>> allow me to create and maintain a straight-forward web application while
>> minimizing the "gotchas" that naturally occur when gluing each layer
>> together.
>>
>> For web framework I've narrowed my candidates down to Grails and Tapestry
>> and am leaning toward Tapestry. But it's hard for me to ignore the Groovy
>> synergy in Grails.
>>
>> Does anyone have recommendations (especially - but not exclusively - if
>> you've used Groovy with Tapestry) on which field I should plant my seeds
>> in?
>>
>> Thank You!
>> Sean
>>
>>
>>
>> --
>> View this message in context: http://tapestry.1045711.n5.**
>> nabble.com/Greenfield-**development-Tapestry-or-**Grails-for-Groovy-dev-*
>> *tp5716732.html<http://tapestry.1045711.n5.nabble.com/Greenfield-development-Tapestry-or-Grails-for-Groovy-dev-tp5716732.html>
>> Sent from the Tapestry - User mailing list archive at Nabble.com.
>>
>> ------------------------------**------------------------------**---------
>> To unsubscribe, e-mail: users-unsubscribe@tapestry.**apache.org<[hidden email]>
>> For additional commands, e-mail: [hidden email]
>>
>>
>
> --
> Thiago H. de Paula Figueiredo
>
>
> ------------------------------**------------------------------**---------
> To unsubscribe, e-mail: users-unsubscribe@tapestry.**apache.org<[hidden email]>
> For additional commands, e-mail: [hidden email]
>
>
Reply | Threaded
Open this post in threaded view
|

Re: Greenfield development: Tapestry or Grails for Groovy dev?

chris@opencsta.org
thank you for sharing your experience alex


On 10/10/2012, at 2:30 PM, Alex Kotchnev wrote:

> In the past five years, I worked on a number of greenfield projects. In
> three out of four, we ended up choosing Grails - it is very hard to deny
> the market & mindshare , the expansive documentation, the big name company
> behind the project, the large community, a massive number of plugins (for
> pretty much anything that you'd want), the end-to-end stack (so, you don't
> have to choose your ORM, DI, etc) and the ease of getting started with a
> Grails project.
>
> However, after working on a couple of these Grails projects for a few
> years, the latest project I got involved with , I chose Tapestry. In some
> cases, I've missed some of the niceties that Grails brings out of the box,
> but without too much effort I've been able to replicate them fairly easily.
>
> The biggest reasons for picking Tapestry over Grails on this latest project
> have been:
> 1. The inability to aggressively refactor your code - the dynamic nature of
> the language is nice when you want to knock something out quickly, and
> saves you a few lines of code here and there. However, after the codebase
> gets to a certain size, the inability to reliably refactor the codebase
> made the codebase difficult to evolve. Sure, IntelliJ & NetBeans has some
> support for refactorings in Groovy; however, it is not even close to the
> level of depth and ease of what you get with Java. I love Groovy to death,
> have been using it for many years (since it was in jsr-1 version) but ...
> the tool support is just not there yet (and likely will never be) and for a
> team of developers Java just ends up being a better choice (at least in the
> context of my team)
>
> 2. The importance of Tapestry components cannot be overstated. In a fairly
> modern web app, the functionality of each page depends on a bunch of
> markup, some CSS from a stylesheet, and some javascript from a javascript
> file. Tapestry makes putting everything together and using the results
> extremely easy and logical. In the late days of the last Grails project I
> was involved in, it was a massive PITA to build a page that really should
> have looked like 'that other one' - even when you used tag libraries to
> encapsulate the markup generation, you still had to hunt down all the css
> and js files that needed to be there.
>
> On the first issue, if you will be using Groovy for your pages, you will be
> in the same boat as Grails. Personally, I wouldn't recommend it - Tapestry
> already pushes the envelope on Java quite a bit, so your Java code ends up
> being very short and sweet already. In the past, I had attempted to use
> Scala in a tapestry app, and ended up having to just deal w/ some of the
> mismatches between the language and the framework and my pages ended up
> looking up like the same old java pages I would have had but with a
> different syntax.
>
> On the second issue, there is the grails resources plugin that tries to
> pull resources kinda like Tapestry, but using it requires this artificial
> separation into resource bundles which seems to be a PITA and somewhat mind
> bending.
>
> On the abundance of Grails plugins - after using a bunch for the projects I
> was working on, it turned out that many were not well maintained so we had
> to take over and maintain them ourselves. Sometimes, they're a good
> starting point, but in the end ended up less of a factor than I initially
> thought.
>
> I originally very much enjoyed the Grails build system (running on top of
> Gradle); however, with a pretty simple project setup, Maven seems to be
> just as straightforward. If you wanted Gradle, you could use that for your
> Tapestry app, and be on-par w/ Grails.
>
> On the latest project that I chose Tapestry for , I have been very happy
> with my choice. On a few occasions I've run into some frustrations (e.g.
> for rendering emails, I ended up having to use Freemarker, whereas with
> Grails the template rendering for emails comes for 'free' ; I had to build
> my own equivalent of the Grails "console" plugin where you can run Groovy
> commands inside of your running application); however, in all cases, the
> solution has turned out to be more elegant than I had expected (albeit, it
> required deeper tweaks in the framework than I had expected).
>
> Cheers,
>
> Alex Kochnev
>
> On Tue, Oct 9, 2012 at 4:17 PM, Thiago H de Paula Figueiredo <
> [hidden email]> wrote:
>
>> I haven't used Groovy myself, but it seems Tapestry and it work very well
>> for a long time. I've found a post by Howard Lewis Ship about this
>> combination in Tapestry 5.0.12, which was an alpha version, all that in
>> 2008: http://tapestryjava.blogspot.**com.br/2008/06/tapestry-with-**
>> groovy.html<http://tapestryjava.blogspot.com.br/2008/06/tapestry-with-groovy.html>.
>> Tapestry doesn't case about the language you use, as long as it generates
>> .class files and you put them in the right places. Some people has used
>> Tapestry with Scala too.
>>
>>
>> On Tue, 09 Oct 2012 16:39:16 -0300, scrotty <[hidden email]> wrote:
>>
>> I am about to create a brand new website. I plan on using Groovy for my
>>> JVM
>>> language (just an arbitrary constraint I imposed on myself as part of the
>>> polyglot experience) and would like to give my users the niceties of AJAX
>>> on
>>> the front end. Everything else: DB, ORM, Web framework, etc. are wide
>>> open.
>>>
>>> I am not new to development in general nor web development in particular.
>>> I
>>> have development experience in all the layers typically used in a web
>>> application (from browser to DB). I am looking for technologies that will
>>> allow me to create and maintain a straight-forward web application while
>>> minimizing the "gotchas" that naturally occur when gluing each layer
>>> together.
>>>
>>> For web framework I've narrowed my candidates down to Grails and Tapestry
>>> and am leaning toward Tapestry. But it's hard for me to ignore the Groovy
>>> synergy in Grails.
>>>
>>> Does anyone have recommendations (especially - but not exclusively - if
>>> you've used Groovy with Tapestry) on which field I should plant my seeds
>>> in?
>>>
>>> Thank You!
>>> Sean
>>>
>>>
>>>
>>> --
>>> View this message in context: http://tapestry.1045711.n5.**
>>> nabble.com/Greenfield-**development-Tapestry-or-**Grails-for-Groovy-dev-*
>>> *tp5716732.html<http://tapestry.1045711.n5.nabble.com/Greenfield-development-Tapestry-or-Grails-for-Groovy-dev-tp5716732.html>
>>> Sent from the Tapestry - User mailing list archive at Nabble.com.
>>>
>>> ------------------------------**------------------------------**---------
>>> To unsubscribe, e-mail: users-unsubscribe@tapestry.**apache.org<[hidden email]>
>>> For additional commands, e-mail: [hidden email]
>>>
>>>
>>
>> --
>> Thiago H. de Paula Figueiredo
>>
>>
>> ------------------------------**------------------------------**---------
>> To unsubscribe, e-mail: users-unsubscribe@tapestry.**apache.org<[hidden email]>
>> For additional commands, e-mail: [hidden email]
>>
>>


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Greenfield development: Tapestry or Grails for Groovy dev?

Kalle Korhonen-2
In reply to this post by Alex Kotchnev-2
Very clear and level-headed reasoning Alex. Would you like to, or
would you mind if I put it up as a blog post on tynamo.org?

Kalle


On Tue, Oct 9, 2012 at 8:30 PM, Alex Kotchnev <[hidden email]> wrote:

> In the past five years, I worked on a number of greenfield projects. In
> three out of four, we ended up choosing Grails - it is very hard to deny
> the market & mindshare , the expansive documentation, the big name company
> behind the project, the large community, a massive number of plugins (for
> pretty much anything that you'd want), the end-to-end stack (so, you don't
> have to choose your ORM, DI, etc) and the ease of getting started with a
> Grails project.
>
> However, after working on a couple of these Grails projects for a few
> years, the latest project I got involved with , I chose Tapestry. In some
> cases, I've missed some of the niceties that Grails brings out of the box,
> but without too much effort I've been able to replicate them fairly easily.
>
> The biggest reasons for picking Tapestry over Grails on this latest project
> have been:
> 1. The inability to aggressively refactor your code - the dynamic nature of
> the language is nice when you want to knock something out quickly, and
> saves you a few lines of code here and there. However, after the codebase
> gets to a certain size, the inability to reliably refactor the codebase
> made the codebase difficult to evolve. Sure, IntelliJ & NetBeans has some
> support for refactorings in Groovy; however, it is not even close to the
> level of depth and ease of what you get with Java. I love Groovy to death,
> have been using it for many years (since it was in jsr-1 version) but ...
> the tool support is just not there yet (and likely will never be) and for a
> team of developers Java just ends up being a better choice (at least in the
> context of my team)
>
> 2. The importance of Tapestry components cannot be overstated. In a fairly
> modern web app, the functionality of each page depends on a bunch of
> markup, some CSS from a stylesheet, and some javascript from a javascript
> file. Tapestry makes putting everything together and using the results
> extremely easy and logical. In the late days of the last Grails project I
> was involved in, it was a massive PITA to build a page that really should
> have looked like 'that other one' - even when you used tag libraries to
> encapsulate the markup generation, you still had to hunt down all the css
> and js files that needed to be there.
>
> On the first issue, if you will be using Groovy for your pages, you will be
> in the same boat as Grails. Personally, I wouldn't recommend it - Tapestry
> already pushes the envelope on Java quite a bit, so your Java code ends up
> being very short and sweet already. In the past, I had attempted to use
> Scala in a tapestry app, and ended up having to just deal w/ some of the
> mismatches between the language and the framework and my pages ended up
> looking up like the same old java pages I would have had but with a
> different syntax.
>
> On the second issue, there is the grails resources plugin that tries to
> pull resources kinda like Tapestry, but using it requires this artificial
> separation into resource bundles which seems to be a PITA and somewhat mind
> bending.
>
> On the abundance of Grails plugins - after using a bunch for the projects I
> was working on, it turned out that many were not well maintained so we had
> to take over and maintain them ourselves. Sometimes, they're a good
> starting point, but in the end ended up less of a factor than I initially
> thought.
>
> I originally very much enjoyed the Grails build system (running on top of
> Gradle); however, with a pretty simple project setup, Maven seems to be
> just as straightforward. If you wanted Gradle, you could use that for your
> Tapestry app, and be on-par w/ Grails.
>
> On the latest project that I chose Tapestry for , I have been very happy
> with my choice. On a few occasions I've run into some frustrations (e.g.
> for rendering emails, I ended up having to use Freemarker, whereas with
> Grails the template rendering for emails comes for 'free' ; I had to build
> my own equivalent of the Grails "console" plugin where you can run Groovy
> commands inside of your running application); however, in all cases, the
> solution has turned out to be more elegant than I had expected (albeit, it
> required deeper tweaks in the framework than I had expected).
>
> Cheers,
>
> Alex Kochnev
>
> On Tue, Oct 9, 2012 at 4:17 PM, Thiago H de Paula Figueiredo <
> [hidden email]> wrote:
>
>> I haven't used Groovy myself, but it seems Tapestry and it work very well
>> for a long time. I've found a post by Howard Lewis Ship about this
>> combination in Tapestry 5.0.12, which was an alpha version, all that in
>> 2008: http://tapestryjava.blogspot.**com.br/2008/06/tapestry-with-**
>> groovy.html<http://tapestryjava.blogspot.com.br/2008/06/tapestry-with-groovy.html>.
>> Tapestry doesn't case about the language you use, as long as it generates
>> .class files and you put them in the right places. Some people has used
>> Tapestry with Scala too.
>>
>>
>> On Tue, 09 Oct 2012 16:39:16 -0300, scrotty <[hidden email]> wrote:
>>
>>  I am about to create a brand new website. I plan on using Groovy for my
>>> JVM
>>> language (just an arbitrary constraint I imposed on myself as part of the
>>> polyglot experience) and would like to give my users the niceties of AJAX
>>> on
>>> the front end. Everything else: DB, ORM, Web framework, etc. are wide
>>> open.
>>>
>>> I am not new to development in general nor web development in particular.
>>> I
>>> have development experience in all the layers typically used in a web
>>> application (from browser to DB). I am looking for technologies that will
>>> allow me to create and maintain a straight-forward web application while
>>> minimizing the "gotchas" that naturally occur when gluing each layer
>>> together.
>>>
>>> For web framework I've narrowed my candidates down to Grails and Tapestry
>>> and am leaning toward Tapestry. But it's hard for me to ignore the Groovy
>>> synergy in Grails.
>>>
>>> Does anyone have recommendations (especially - but not exclusively - if
>>> you've used Groovy with Tapestry) on which field I should plant my seeds
>>> in?
>>>
>>> Thank You!
>>> Sean
>>>
>>>
>>>
>>> --
>>> View this message in context: http://tapestry.1045711.n5.**
>>> nabble.com/Greenfield-**development-Tapestry-or-**Grails-for-Groovy-dev-*
>>> *tp5716732.html<http://tapestry.1045711.n5.nabble.com/Greenfield-development-Tapestry-or-Grails-for-Groovy-dev-tp5716732.html>
>>> Sent from the Tapestry - User mailing list archive at Nabble.com.
>>>
>>> ------------------------------**------------------------------**---------
>>> To unsubscribe, e-mail: users-unsubscribe@tapestry.**apache.org<[hidden email]>
>>> For additional commands, e-mail: [hidden email]
>>>
>>>
>>
>> --
>> Thiago H. de Paula Figueiredo
>>
>>
>> ------------------------------**------------------------------**---------
>> To unsubscribe, e-mail: users-unsubscribe@tapestry.**apache.org<[hidden email]>
>> For additional commands, e-mail: [hidden email]
>>
>>

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Greenfield development: Tapestry or Grails for Groovy dev?

Lance Java
In reply to this post by Alex Kotchnev-2
That was a great read Alex, thanks for sharing.

On the subject of rendering emails, I've got a service that can render components without the need for a web request. It returns a JSONObject containing the content and the javascript etc that is normally sent to the browser. It does this by spoofing a request and response. I required this for push but perhaps I could extract it out to provide offline templating for emails etc.

https://github.com/uklance/tapestry-cometd/blob/master/src/main/java/org/lazan/t5/cometd/services/internal/ComponentJSONRendererImpl.java
Reply | Threaded
Open this post in threaded view
|

Re: Greenfield development: Tapestry or Grails for Groovy dev?

Taha Hafeez
In reply to this post by Kalle Korhonen-2
To add to what Alex has already said,

IMHO the main difference between Grails and Tapestry is the so called "MVC architecture" vs component based architecture. Some developers are comfortable with the former while some prefer the latter and that is a very important factor for me.  

I have worked on Rails, spring mvc like frameworks and I find myself writing a lot more code with these frameworks and I always miss the abstraction that components bring to the table.

Also as Alex said, there may not be many ready to use plugins available for tapestry but it is really easy to create one.

One way to find the answer to your question, if you have time :),  is to create small reference apps with both your choices and you might find the answer before you complete the apps :)

regards
Taha

On Oct 10, 2012, at 10:39 AM, Kalle Korhonen wrote:

> Very clear and level-headed reasoning Alex. Would you like to, or
> would you mind if I put it up as a blog post on tynamo.org?
>
> Kalle
>
>
> On Tue, Oct 9, 2012 at 8:30 PM, Alex Kotchnev <[hidden email]> wrote:
>> In the past five years, I worked on a number of greenfield projects. In
>> three out of four, we ended up choosing Grails - it is very hard to deny
>> the market & mindshare , the expansive documentation, the big name company
>> behind the project, the large community, a massive number of plugins (for
>> pretty much anything that you'd want), the end-to-end stack (so, you don't
>> have to choose your ORM, DI, etc) and the ease of getting started with a
>> Grails project.
>>
>> However, after working on a couple of these Grails projects for a few
>> years, the latest project I got involved with , I chose Tapestry. In some
>> cases, I've missed some of the niceties that Grails brings out of the box,
>> but without too much effort I've been able to replicate them fairly easily.
>>
>> The biggest reasons for picking Tapestry over Grails on this latest project
>> have been:
>> 1. The inability to aggressively refactor your code - the dynamic nature of
>> the language is nice when you want to knock something out quickly, and
>> saves you a few lines of code here and there. However, after the codebase
>> gets to a certain size, the inability to reliably refactor the codebase
>> made the codebase difficult to evolve. Sure, IntelliJ & NetBeans has some
>> support for refactorings in Groovy; however, it is not even close to the
>> level of depth and ease of what you get with Java. I love Groovy to death,
>> have been using it for many years (since it was in jsr-1 version) but ...
>> the tool support is just not there yet (and likely will never be) and for a
>> team of developers Java just ends up being a better choice (at least in the
>> context of my team)
>>
>> 2. The importance of Tapestry components cannot be overstated. In a fairly
>> modern web app, the functionality of each page depends on a bunch of
>> markup, some CSS from a stylesheet, and some javascript from a javascript
>> file. Tapestry makes putting everything together and using the results
>> extremely easy and logical. In the late days of the last Grails project I
>> was involved in, it was a massive PITA to build a page that really should
>> have looked like 'that other one' - even when you used tag libraries to
>> encapsulate the markup generation, you still had to hunt down all the css
>> and js files that needed to be there.
>>
>> On the first issue, if you will be using Groovy for your pages, you will be
>> in the same boat as Grails. Personally, I wouldn't recommend it - Tapestry
>> already pushes the envelope on Java quite a bit, so your Java code ends up
>> being very short and sweet already. In the past, I had attempted to use
>> Scala in a tapestry app, and ended up having to just deal w/ some of the
>> mismatches between the language and the framework and my pages ended up
>> looking up like the same old java pages I would have had but with a
>> different syntax.
>>
>> On the second issue, there is the grails resources plugin that tries to
>> pull resources kinda like Tapestry, but using it requires this artificial
>> separation into resource bundles which seems to be a PITA and somewhat mind
>> bending.
>>
>> On the abundance of Grails plugins - after using a bunch for the projects I
>> was working on, it turned out that many were not well maintained so we had
>> to take over and maintain them ourselves. Sometimes, they're a good
>> starting point, but in the end ended up less of a factor than I initially
>> thought.
>>
>> I originally very much enjoyed the Grails build system (running on top of
>> Gradle); however, with a pretty simple project setup, Maven seems to be
>> just as straightforward. If you wanted Gradle, you could use that for your
>> Tapestry app, and be on-par w/ Grails.
>>
>> On the latest project that I chose Tapestry for , I have been very happy
>> with my choice. On a few occasions I've run into some frustrations (e.g.
>> for rendering emails, I ended up having to use Freemarker, whereas with
>> Grails the template rendering for emails comes for 'free' ; I had to build
>> my own equivalent of the Grails "console" plugin where you can run Groovy
>> commands inside of your running application); however, in all cases, the
>> solution has turned out to be more elegant than I had expected (albeit, it
>> required deeper tweaks in the framework than I had expected).
>>
>> Cheers,
>>
>> Alex Kochnev
>>
>> On Tue, Oct 9, 2012 at 4:17 PM, Thiago H de Paula Figueiredo <
>> [hidden email]> wrote:
>>
>>> I haven't used Groovy myself, but it seems Tapestry and it work very well
>>> for a long time. I've found a post by Howard Lewis Ship about this
>>> combination in Tapestry 5.0.12, which was an alpha version, all that in
>>> 2008: http://tapestryjava.blogspot.**com.br/2008/06/tapestry-with-**
>>> groovy.html<http://tapestryjava.blogspot.com.br/2008/06/tapestry-with-groovy.html>.
>>> Tapestry doesn't case about the language you use, as long as it generates
>>> .class files and you put them in the right places. Some people has used
>>> Tapestry with Scala too.
>>>
>>>
>>> On Tue, 09 Oct 2012 16:39:16 -0300, scrotty <[hidden email]> wrote:
>>>
>>> I am about to create a brand new website. I plan on using Groovy for my
>>>> JVM
>>>> language (just an arbitrary constraint I imposed on myself as part of the
>>>> polyglot experience) and would like to give my users the niceties of AJAX
>>>> on
>>>> the front end. Everything else: DB, ORM, Web framework, etc. are wide
>>>> open.
>>>>
>>>> I am not new to development in general nor web development in particular.
>>>> I
>>>> have development experience in all the layers typically used in a web
>>>> application (from browser to DB). I am looking for technologies that will
>>>> allow me to create and maintain a straight-forward web application while
>>>> minimizing the "gotchas" that naturally occur when gluing each layer
>>>> together.
>>>>
>>>> For web framework I've narrowed my candidates down to Grails and Tapestry
>>>> and am leaning toward Tapestry. But it's hard for me to ignore the Groovy
>>>> synergy in Grails.
>>>>
>>>> Does anyone have recommendations (especially - but not exclusively - if
>>>> you've used Groovy with Tapestry) on which field I should plant my seeds
>>>> in?
>>>>
>>>> Thank You!
>>>> Sean
>>>>
>>>>
>>>>
>>>> --
>>>> View this message in context: http://tapestry.1045711.n5.**
>>>> nabble.com/Greenfield-**development-Tapestry-or-**Grails-for-Groovy-dev-*
>>>> *tp5716732.html<http://tapestry.1045711.n5.nabble.com/Greenfield-development-Tapestry-or-Grails-for-Groovy-dev-tp5716732.html>
>>>> Sent from the Tapestry - User mailing list archive at Nabble.com.
>>>>
>>>> ------------------------------**------------------------------**---------
>>>> To unsubscribe, e-mail: users-unsubscribe@tapestry.**apache.org<[hidden email]>
>>>> For additional commands, e-mail: [hidden email]
>>>>
>>>>
>>>
>>> --
>>> Thiago H. de Paula Figueiredo
>>>
>>>
>>> ------------------------------**------------------------------**---------
>>> To unsubscribe, e-mail: users-unsubscribe@tapestry.**apache.org<[hidden email]>
>>> For additional commands, e-mail: [hidden email]
>>>
>>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Greenfield development: Tapestry or Grails for Groovy dev?

Szemere Szemere-2
In reply to this post by Lance Java
I've used both Tapestry (nearly 5 years) and Grails (1 year before junking
application).

Grails has some really nice features, such as url mapping and the built-in
MVC framework.

I didn't like:
1) Lack of type-safety. Many errors would present themselves only at
runtime, which slowed productivity and in worst cases, resulted in errors
in production.

2) The incantations required to generate scaffolding - they are obscure and
require reading the manual in as much detail as just copy and pasting
similar code

3) Plugins and core system versions were often incompatible. This required
careful version management.

Versus Tapestry, the +/-s
a) Tapestry has been rock solid and stable - very few critical bugs in the
core framework. Similarly with the limited plugins we use.
b) It's fairly complex to learn - particularly the request lifecycle and IOC
c) Sometimes there's too much Java magic, which is hard to understand eg.
byte code enhancement of page classes
d) Does things its own way when a standard solution would have been easier
to understand and maintain eg. homegrown IOC.  Wrt Tapestry IOC, I still
haven't got my head round the annotations on method parameters, together
with specially named parameters versus Guice's explicit Module constructor
w/ explicit bind calls. Tapestry methodology is too many steps of magic, as
opposed to simply leaving the one step of IOC object lookup and binding
magic - like the math prof who skips 2-3 steps of reasoning which are only
obvious if you know the technique well.

In short, I would definitely recommend Tapestry above Grails, but I feel
that there is better yet to come in the web frameworks arena.

Szemere
Reply | Threaded
Open this post in threaded view
|

Re: Greenfield development: Tapestry or Grails for Groovy dev?

Alex Kotchnev-2
Sean,
  I missed this in my original post, but Szemere's post reminded me of
another issue w/ Grails.

Although I agree that at times, there is quite a bit of 'magic' that
happens under the covers in Tapestry, it's nothing to the amount of magic
that happens in Grails. For a seasoned java developer (with knowledge of
all the underlying frameworks for grails - e.g. Hibernate, Spring,
Sitemesh), getting started on a Grails project seemed like a very easy
proposition - you just had to learn a few conventions here, a few magic
method calls there, some mapping magic, some validation magic.. and it
seemed easy. After working on the grails project for a while (and the team
adding a few more layers of magic into the grails setup like service
injection into any object in the app), we added a brand new developer to
the team, and I realized how convoluted the thing had become. When I would
attempt to help out with an issue, I'd catch myself having to know about
multiple layers of 'magic' to explain how something works, which made the
learning curve for Grails pretty steep as well, particularly for a 'new'
developer.

In the technology evaluation phase of the current project, I did exactly
what was suggested a bit further up : I created two simple applications and
added some basic functionality to showcase templating, validation,
components/encapsulation, services, security and Grails and Tapestry were
the front runners (not so far behind were Wicket and Play).

On the maintainability of Grails application - technically, I'm sure you
can make the application be as maintainable and as evolvable as a vanilla
Java/Tapestry app. You could certainly write your domain/service model in
Java and have great refactoring capability. If you want to take it a step
further, you can even have the controllers in Java. It's just that the
defaults you start with encourage the one-off approach to things and you
end up paying for it down the line (which might be fine if the application
you built turns out to be successful and maintenance-worthy).

If you haven't already done so, I'd suggest posting a similar question on a
Grails mailing list and see what kind of answers you get (I'd be curious
about seeing them as well if you do so).

Cheers,

Alex K
On Wed, Oct 10, 2012 at 4:46 AM, Szemere Szemere
<[hidden email]>wrote:

> I've used both Tapestry (nearly 5 years) and Grails (1 year before junking
> application).
>
> Grails has some really nice features, such as url mapping and the built-in
> MVC framework.
>
> I didn't like:
> 1) Lack of type-safety. Many errors would present themselves only at
> runtime, which slowed productivity and in worst cases, resulted in errors
> in production.
>
> 2) The incantations required to generate scaffolding - they are obscure and
> require reading the manual in as much detail as just copy and pasting
> similar code
>
> 3) Plugins and core system versions were often incompatible. This required
> careful version management.
>
> Versus Tapestry, the +/-s
> a) Tapestry has been rock solid and stable - very few critical bugs in the
> core framework. Similarly with the limited plugins we use.
> b) It's fairly complex to learn - particularly the request lifecycle and
> IOC
> c) Sometimes there's too much Java magic, which is hard to understand eg.
> byte code enhancement of page classes
> d) Does things its own way when a standard solution would have been easier
> to understand and maintain eg. homegrown IOC.  Wrt Tapestry IOC, I still
> haven't got my head round the annotations on method parameters, together
> with specially named parameters versus Guice's explicit Module constructor
> w/ explicit bind calls. Tapestry methodology is too many steps of magic, as
> opposed to simply leaving the one step of IOC object lookup and binding
> magic - like the math prof who skips 2-3 steps of reasoning which are only
> obvious if you know the technique well.
>
> In short, I would definitely recommend Tapestry above Grails, but I feel
> that there is better yet to come in the web frameworks arena.
>
> Szemere
>
Reply | Threaded
Open this post in threaded view
|

Re: Greenfield development: Tapestry or Grails for Groovy dev?

scrotty
Thank you all so much for these excellent and detailed answers! This is more than I expected but exactly what I was hoping for.

I followed Alex's recommendation and have cross-posted to the Grails mailing list: http://grails.1312388.n4.nabble.com/Greenfield-development-Tapestry-or-Grails-for-Groovy-dev-td4636279.html

Please don't let my "thank you" now dissuade you from adding your own response. I would like to hear everything I can on the subject.

Thanks Again!
Sean