GWT+Roo a few days later

[Amir Kashani]

I've been playing with Roo & GWT for a couple of days now, which
certainly doesn't make me an expert, but I'd like to share my
experience and see how it compares with others.

The application that I'm trying to create has about 8 entities that
require a CRUD like interface. The rest of the application requires a
more specific (non-CRUD) UI. My hope was that Roo would help generate
the CRUD portions, just allowing for some basic customizations, and
let me handle the rest. So far, I seem to be fighting it more than
it's helped. Some examples:

- You can't modify the generated ui.xml files -- Roo will simply
clobber them as soon as it makes the next change for that entity. For
example, I don't want to list the ID field in the list view, but I
don't see a way to remove it. There's a JIRA open about this, that was
deferred to post 1.1.0 (ROO-937).

- New dynamic finders don't seem to be added to the respective Request
interface. Further, and this may be a Roo thing, they return
TypedQuery rather than a List or the entity, which I don't imagine the
RequestFactory framework can handle. There's another JIRA than covers
this, I believe (ROO-1595)

- Adding custom finders doesn't work, because again, Roo will clobber
the Request interface. I tried removing the @RooGwtMirroredFrom
annotation from the Request, but Roo just readied it for me. Probably
under the previous JIRA.

Lastly, the documentation is atrocious. The Roo reference guide only
mentions GWT in its appendix of commands, and other guides only go as
far as a simple "gwt setup". There's no mention of the expectations,
limitations, guide to customization, or anything else. I've seen
several, yet unanswered posts on the Roo forum about customization, so
I imagine I'm not alone here.

I've been a very loyal GWT user since 1.3, and I'm very pleased with
the ongoing progress, including the gamut of features introduced in
2.1, so I hope nobody takes this as GWT bashing. However, unless I'm
really missing something, the implementation of Roo+GWT falls far
short of the hype it's received since I/O. In the current form, it
makes for a very impressive demo: type a few commands and a full
functioning database editor pops out. But as soon as you try to do
anything outside of what's generated, it's very hard, if not
impossible.

So, it's only been a few days since final release, but what do other
people think? Is anyone having better luck?

Thanks.

- Amir

[Sankalp]

I'd like to voice my thoughts on this, but first a fairly big caveat:
I am far from a GWT expert.

I'd dabbled with it for work-related purposes at my last job, but the
focus of what I worked on was definitely not GWT. (One of our products
was a SaaS app whose UI is built almost exclusively on GWT; our other
product also used GWT for admin-related UIs, which were embedded in a
thick-client app.) I'm familiar with a lot of the concepts, but I've
never had a need to build something ground-up with GWT; so perhaps a
lot of my experience with GWT+Roo has been tainted by the fact that
I'm still fairly new on the GWT learning curve. That being said, I
generally pride myself on learning quickly :)

I was looking for a way to jumpstart a project I've been working on
that would allow me to use GWT on the client to talk to a fairly
straightforward data back-end. I didn't want to spend bundles of time
writing tedious plumbing code, as I really wanted to get up and
running ASAP; Roo seemed perfect since it handles a lot of the
boilerplate codegen, etc. Indeed, it is ideal for this; I had a very
basic CRUD app up and running with my handful of entities in a matter
of minutes. (Incidentally - one of the details that I think is perhaps
often overlooked is the fact that you also get a nicely codegenned
build/test system; this is typically a lot of annoying plumbing as
well that Just Worked with Roo.) It was only after the first ten
minutes that I was exposed to the full brunt of the learning curve...

I too have found that any attempt to stray from the cookie-cutter CRUD
app requires a fair bit of self-investment in reading the generated
code, etc. One of the things I'm currently fighting is that the MVP
patterns that are generated by Roo do not quite match the GWT 2.1 docs
and what they outline for their Hello World app. In particular, the
bits around how activity mappers are implemented in Roo-generated code
are quite different from the docs. (Actually, a fair bit of thanks
goes to you, Amir! Your post on GWT 2.1 MVP with Gin addresses a lot
of my recent confusion around the subject: check out
https://groups.google.com/group/google-web-toolkit/browse_thread/thread/2ed199a42c500156
for those who haven't seen the post.) What I actually found to be more
sensible was to create a parallel ground-up GWT module/entrypoint,
while trying to reuse at least some of the generated code, where
possible. Largely, I've found that I cannot; the code is fairly
tightly-bound to the notion of a master/details-style CRUD interface;
while this would be a huge time saver for a number of different types
of apps, it's unfortunately of little value to me, at least as I've
been delving into it the past week or two.

However, none of that inherently bothers me; there *is* still a bit of
usable generated code (specifically the entity proxies and related
code); there are certainly a few annoying bugs I ran into (the issue
with adding new finders is something I ran into right away), but I was
able to at last get past these for now. My biggest concern about GWT
+Roo is the utter lack of documentation of the GWT-specific pieces as
they relate to a Roo-built app. I've basically had to try and take the
knowledge gained from the GWT docs (e.g., re: Activities/Places-style
MVP) and map it to the generated code, with an attempt to understand
what was generated and why. I think at least a basic discussion on
typical customizations (e.g., adding a finder) or limitations of the
generated code would be a must for docs to cover. I'd also like to see
a bit of analysis into the basic architecture of the generated UI
code; this would have helped me a lot (though perhaps this was just me
also trying to learn the GWT 2.1 patterns in conjunction with what Roo
generated). Additionally, I have also observed that a lot of the forum
posts about GWT+Roo tend to remain unanswered or have been thus far
identified as known issues (suggesting a lack of project maturity).

That being said - while I'm troubled by the paucity of docs - I am
well aware that this is all fairly bleeding-edge stuff, and I'm
posting my experiences simply to share them, and hardly to bash GWT or
Roo. I am very intrigued by the possibilities of what the toolkit
could offer. If nothing else, at least as it stands today, Roo+GWT
generates everything just shy of a usable UI for your code, leaving
you to implement those pieces yourself. This coupled with all the data-
binding goodness that now exists in GWT 2.1 I think can still make for
a powerful toolkit, and can make Roo+GWT quite successful.

So, in short - am I having better luck? I have to say, I'm afraid I'm
not :( However, I'm still excited by what's there - because what is
there *does* work, and that means it's already saved me time by not
having to re-invent boilerplate plumbing.

Sankalp

[dr1337]

I too have recently been playing around with GWT and Spring Roo over
the past few days to see what all the hype was about during Google IO.
So far, my assessment of it has been similar to yours Amir. It's great
if all you need is a simple UI for a database editor but anything else
that requires more customisation, you're probably better off hand
coding it and doing your own plumbing.

I've never used the Spring Framework so perhaps if you have some
experience using it, then that might make using GWT easier for you.
Currently the lack of documentation coupled with having to manually
read the code to figure out what's going on has proven to be too much
of a time investment for what its worth. Until a better tutorial than
the tech demo at Google IO is made, I'll probably stick to doing
things the old but familiar way.

[zixzigma]

is there a way to tell Roo to just generate Places or just
Presenters ? instead of everything ?
the thing is with CRUD part of app, there is a mapping between
Entities(entityproxies) and Places/Activity/Presenters.

but there are times that many entities need to collaborate to present
the information to the user.
the data is not coming from one entity, rather 3-4 entities.
in this case, Roo generates Presenter/Acitivity/Places/Views that are
not going to be used.

because those 4 entities would be presented by one complex widget.

the first thing Roo asks is : give me your domain models.
what about asking for Places ? or Presenters ?

i had developed GWT apps using MVP, prior to Roo release.
and i understand the exampes, concepts, and Roo generated code.
but have difficulty creating a non-crud app with Roo.

and writing MVP without Roo is very difficult, lots of scaffolding
code.
there are other frameworks, such as GWTP, i had found it more easier
to work with.
but since Google's MVP is out, want to give that a try.

so, i'm in the same boat, experimenting.

[Jim Northrup]

this style of project dates back to corba days.

i have a roo project far from mature but what we've sussed out so far:

* inherit from the templates
* use echo quit|roo in hudson, and don't check in the roo turds,
use .gitignore/svnignore etc.
* roo's file system scanner is inadequate at completing large passes
of fresh changes, at least on ubuntu64, so use echo quit|roo instead
of camping in the roo shell
* ignore non-JPA features at this time, vmware wants your project "to
be continued" long enough to let them finish (marketing thier
paywalled) docs.

my toplevel .gitignore:

classes
.classpath
.directory
foreel.iml
foreel.ipr
foreel.iws
foreel.properties
foreel.script
.idea
*.iml
*.ipr
*.iws
log.roo
.metadata
META-INF
otherdirectoryvalue
out
proj
.project
.settings
.springBeans
target
test-classes
war
*_Roo_*

(also a .gitignore exists above "managed" dir in gwt client)

[koma]

Completely following Amir's conclusion... don't go the Spring Roo way.
Finding some useful code after the clutter is the main challenge;

Moreover, the dependencies on Maven - yikes....

Try to get deeper understanding programming GWT 2.1 by hand - this
blog series is great : http://tbroyer.posterous.com/

K.