To GWT Roo or not to GWT Roo, especially when more complex than basic CRUD?

[dprpme]

Hi all,

I came across Spring Roo recently and have put in a considerable amount of research as far as whether to use it for my app or not. However, I'm running into a couple of issues in my consideration.

1) GWT support (Spring support for GWT/addon?):
Spring Roo integration with GWT (more specifically the gwt addon for Roo to make MVP life easier) was presented back in 2010 in the IO keynote (http://www.youtube.com/watch?v=GQHlhIIxCIc) and in a talk by Ray Ryan (http://www.youtube.com/watch?v=M5x6E6ze1x8) and it seemed promising. However, in all my googling it seems like the gwt-roo presence/community has been sorely lacking, is it just me? Is GWT still on the Roo bandwagon? The last doc on it by gwt (https://developers.google.com/web-to...torial/roo-sts) still references 2.1, and if you following it currently, all the STS side stuff doesn't run properly (at least it didn't for me).

2) My app is going to be more complex than simple CRUD. Ideally, if I were to use Roo, I would only want it to do it's "magic" for the Model/domain layer, but leave the Presenter and View layers to me and not interfere with them. In all my searching I couldn't find any docs referencing this specifically (aside from some obscure blog posts which are even direct). Is it that it's not possible or too hairy? Or am I trying to have my cake and eat it too?

3) Finally, does the community even recommend using Roo instead of just going with RequestFactory and just writing the services yourself (for Model/domain interaction)? Do the benefits of using Roo outweigh the drawbacks when aiming for a more-than-CRUD app?

I did find a post by K. Rimple which was a little disconcerting: http://www.coderanch.com/t/582623/Spring/Spring-Roo-GWT, is this still the case?

I love the idea of being able to declare a field in my entity and having dev time shell create the corresponding boilerplate stuff for the model and services communication, but not if it's going to be a huge headache trying to set it up so that it will do that properly.

Thanks in advance for any suggestions, comments, help, I know this was a little long....I really appreciate it.

-Seth

[delgad9]

@dprpme,

Please, tell me 3 features about GWT that are making you choosing it....

You can refer more if you can or want.

I might have an -viable SR- alternative for you but I need to know whether or not matches your expectations.


Thank you
jD @http://pragmatikroo.blogspot.com

[spgmx]

2) My app is going to be more complex than simple CRUD. Ideally, if I were to use Roo, I would only want it to do it's "magic" for the Model/domain layer, but leave the Presenter and View layers to me and not interfere with them. In all my searching I couldn't find any docs referencing this specifically (aside from some obscure blog posts which are even direct). Is it that it's not possible or too hairy? Or am I trying to have my cake and eat it too?

It works, not hairy.
But... what gives you Roo when you only create the domain, data and service layer with it? Not much...
In the past I thought too, that this is a good way to use Roo. But really, more cons than pros...
All this IDT stuff is a bit strange and does not fit 100% into the IDE although the AspectJ-Dev-Tools in Eclipse.

The big advantage of Roo is that it creates the whole stack, from domain to UI, where the UI is the part where a developer has really much to do. If you cut off the UI - there not much work to do for Roo what a smart developer with a smart IDE cannot do nearly as fast as Roo.

3) Finally, does the community even recommend using Roo instead of just going with RequestFactory and just writing the services yourself (for Model/domain interaction)? Do the benefits of using Roo outweigh the drawbacks when aiming for a more-than-CRUD app?

I would use Roo only when:

* the really bigger part of my app is 100% CRUD.
OR
* I'm an expert in writing Roo addons

Personally I think Roo is dead.

[dprpme]

Hi JD,

I actually came across a couple of your posts regarding Roo on the interwebs and looked at your blog before posting here .

I say the big 3 reasons for going with GWT (aside from having already invested a considerable amount of time with it) and when considering that I'm going for an actual Web 2.0 application and so the client will definitely be thicker than the server side I'd say the reasons are:

1) Java and its powerful tools, a language I'm more familiar with Java than JS and great IDEs. Debugging, quick dev time.
2) Highly optimized compilation to JS and flexibility.
-I've taken a look at what the actual compiler does and it's simply quite amazing.
-A non-dynamic language like Java affords you the ability to remove dead code and only deliver what would be used so you can code to your hearts content in Java but only deliver the most compact version in JS.
-Abstraction of async calls and complications and a plethora of other very convenient performance optimizing features (e.g. code-splitting, deferred-binding, clientbundles and resources, etc.)
3) A very active community (not to say that roo doesn't) with continued support bringing more features and optimizations and performance metrics

If you have an alternative that offers all of that and more, I'm sold .

Thanks again,

-seth

[dprpme]

Hi spgmx,

Thanks a lot for your insight. I was leaning towards your thoughts on that matter as well as that is what all my searching seemed to come up with, I just wanted to make sure there wasn't something I was missing or overlooking. But I think you articulated it perfectly.

Thanks again,

-Seth

[delgad9]

Hello Seth,

If you have an alternative that offers all of that and more, I'm sold.

As a matter of fact I-do-I-do...

The alternative is called: "Seth", the real developer that lives inside yourself.
And I want you think about it, because I am serious and not metaphorical on the point.

I agree and like your points but bottom line what we are discussing here are better ways to implement Web 2.0 Java applications. I don't think a real "paying-you-to-create-a-solution" User will care much about "optimized compilation" and that stuff. They want cost-effective solution delivered on budget. That's it.

On your point about an active community. You might be right but the fact is...there are only 464 GWT jobs vs 907 JSF advertized today. I don't say JSF is better than GWT. I am making the point the JSF has twice the market*.


Now. I think there is totally wrong expectation that Roo will come up with complete solutions out of the bat.
Roo doesn't cure the flu too. Just in case someone out there might have this expectation too.

Roo is only the beginning of the project NOT THE END. IMHO this is the very first thing you have to understand for using Roo correctly.

Personally, I think Roo is sitting on the bench. Waiting for a competent -with winning mentality- coach that call it to win the game for the enterprise Java community.

I hope you are still "sold" with my alternative as you mentioned. Because is the best and only one I have.


B. Roogards

jD @ http://pragmatikroo.blogspot.com

Final note: Use frameworks, apis, libraries, etc the empower the Developer not turn them in commodities.
* jQuery+ java has 2144 jobs advertized

[dprpme]

Hi JD,

I like your point, quite inspirational . However the project has already been started and has invested in GWT. The major concerns for the project are scalability and performance, it's not based on a user's dime. So these have to be at the forefront of consideration. If we were working on the user's dime, you'd definitely be on the money.

Thanks again for your input, it really was appreciated, and definitely something to take into consideration for any future projects.

-Seth

[delgad9]

Seth,

You are welcome...

Keep the following reference under your sleeve. You can create any gwt type web app with spring web mvc + jquery anytime.

As shown in this mini-article http://pragmatikroo.blogspot.com/201...-mvc-view.html


Spring Roo is used for starting the project, of course.

Just trying to be ( informa + inspira ) tional

B. & revolted on the users Roogards
jD

[spgmx]

Roo is a very powerful tool, but it lacks more powerful addons. This is what it makes not very useable besides CRUD webapps.

You may try to write addons, here is a VERY simple example: http://www.youtube.com/watch?v=_VMmzaUxE0c

The addon stuff is very powerful, but it's all very abstract and complicated and you must be a very good developer to build powerful addons. All samples I have every seen were "Hello world" addons like this in the video.

[delgad9]

Roo is a very powerful tool, but it lacks more powerful addons. This is what it makes not very useable besides CRUD webapps.

You may try to write addons, here is a VERY simple example: http://www.youtube.com/watch?v=_VMmzaUxE0c

The addon stuff is very powerful, but it's all very abstract and complicated and you must be a very good developer to build powerful addons. All samples I have every seen were "Hello world" addons like this in the video.

Most importantly than having powerful add-ons for Roo, -addons would be of great convenience, no question about that-; would be to show to the interested Spring Roo community on how to use the baseline to solve many of their real-world problems.

I've solved many of the questions post in the forum just by using Roo baseline: This is basically the purpose of my web site http://pragmatikroo.blogspot.com.

To solve real-world web development requirements using Spring Roo. No just World-Hello or CRUD stuff.

B. Roogards
jD