GWT 2.1.0 M1 and Roo development lifecycle. What would you do?

[Marco De Angelis]

I've been giving a closer look at GWT 2.1.0 M1 and Expense application
lately, as the best way to be educated after Google I/O 2010 sessions.
In your opinion, how long a real-world application shall be coupled
with Spring Roo infrastructure/annotations?

It's obvious that the default views generated by Spring Roo will be
replaced by custom views developed with specific application logic.
Even if you're a CSS wizard, at some point in time you would need a
custom behaviour. I can see the following approaches:

1) Remove all references to Roo. The Expenses application has, in
fact, removed the AspectJ extensions, all Roo annotations and just
reused the skeleton of Entity+Record+Places+Activities as basis for
custom views. If you have to add a new field or a new entity after
abandoning roo, you're own your own.

2) Like 1), but keep the original Roo project somewhere in parallel.
If you have to modify something, you can still use Roo to generate new
classes and fields scaffolding, and then manually copy/paste/adjust in
the real-world application. Not so integrated, but it may work if your
views and logic change more often than the model does.

3) You keep roo as part of the development cycle. You place your
custom views in separate package, and add your own modules that use
your own widgets instead of the scaffolding ones. In this way, roo can
always rebuild the entire scaffolding without interfering with your
code. You still have to manually adjust your custom views to handle
new/removed/modified fields and entities. Very nice integration, but
you need to know exactly what Roo is going to ovewrite when things
change.

4) I have a little knowledge of Roo, so there might be extension
points that I'm not aware of. In that case there might be other ways
to add your own views.

I'm tempted to think approach 2) is the classical good-enough
compromise, but I'm interested in other people's opinion.

[anjan bacchu.dev]

Hi Marco,

  I'm inclined to go with approach #2 as well for the same reasons you've mentioned below.

BR,

~A

--
You received this message because you are subscribed to the Google Groups "Google Web Toolkit" group.
To post to this group, send email to google-we...@googlegroups.com.
To unsubscribe from this group, send email to google-web-tool...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/google-web-toolkit?hl=en.

[André Moraes]

I'm not using the integration with Roo, but I dislike the idea of
having a tool that after generating my code difficult to customize the
generated code.

A while ago I wrote a code generator that allows reuse of code and
Retrieval without losing the customizations made.

Through some markings (in comments) in the code the user can define
the points where he wants to insert customizations.

Thus, the tool does not enter the path and the user has more control
over the generated code and customizations future.

Follow the link from the tool:
http://code.google.com/p/am-code-generator/

The documentation on using the tool is not very good, but it is quite
simple.

I'll try to commit some examples of how to generate code using the
tool.
Any comments or criticism is welcome.

I am available for any questions.

[Jaroslav Záruba]

2010/6/18 André Moraes <and...@gmail.com>

I'm not using the integration with Roo, but I dislike the idea of
having a tool that after generating my code difficult to customize the
generated code.

Roo keeps your code untouched. It stores the modifications elsewhere and merges those files at compilation-time.

[Jaroslav Záruba]

Well not exactly like that but it does not mess-up your code irreversibly.

Here is kind-of introduction if you haven't seen it already: http://www.infoq.com/presentations/Introducing-Spring-Roo

(Don't go fullscreen when watching the video, there goes a screen-cast under its frame.)

2010/6/19 Jaroslav Záruba <jarosla...@gmail.com>

[André Moraes]

Jaroslav,

But how can I control the merge process?
In my case the code is generated, than i can edit make any changes in
the generated code (which will be preserved by the safe-code-marks)
and then the GWT compiler (or any other compiler) will compile the
code that i wrote.

I don't really know/use Roo, but I used some code generation tools
before, so excuse me for any noob comment on the Roo subject.

On 18 jun, 19:08, Jaroslav Záruba <jaroslav.zar...@gmail.com> wrote:
> 2010/6/18 André Moraes <andr...@gmail.com>

[Jaroslav Záruba]

I don't dare teach anyone Roo, I'm yet to try it myself. :) Let me only tell you that I'm having pretty similar concerns to yours whenever I hear "code generation". And after watching the video I know I will try it, it has impressed me enough.

2010/6/19 André Moraes <and...@gmail.com>

[André Moraes]

Jaroslav,

I took a look in the Spring Roo videos and made a little notion on how
you it works.

I wrote some programs when in college with the AspectJ (the base of
the Spring Roo) and it was very nice to have custom aspects around my
java classes.

I think the main problem, at least for me, with the Roo tools is that
it works basically only for the Java Plataform.

I don't found any links on how to use only GWT + Roo whithout any
server code.

Anyway, i uploade some samples using my code template to generate some
GwtEvents (the base for the MVP cool development in GWT).

Thanks for the links, maybe when in a only Java project I consider
using and learning more Spring Roo.

On 18 jun, 19:27, Jaroslav Záruba <jaroslav.zar...@gmail.com> wrote:
> I don't dare teach anyone Roo, I'm yet to try it myself. :) Let me only tell
> you that I'm having pretty similar concerns to yours whenever I hear "code
> generation". And after watching the video I know I will try it, it has
> impressed me enough.
>

> 2010/6/19 André Moraes <andr...@gmail.com>

>
>
>
> > Jaroslav,
>
> > But how can I control the merge process?
> > In my case the code is generated, than i can edit make any changes in
> > the generated code (which will be preserved by the safe-code-marks)
> > and then the GWT compiler (or any other compiler) will compile the
> > code that i wrote.
>
> > I don't really know/use Roo, but I used some code generation tools
> > before, so excuse me for any noob comment on the Roo subject.
>
> > On 18 jun, 19:08, Jaroslav Záruba <jaroslav.zar...@gmail.com> wrote:
> > > 2010/6/18 André Moraes <andr...@gmail.com>
>
> > > > I'm not using the integration with Roo, but I dislike the idea of
> > > > having a tool that after generating my code difficult to customize the
> > > > generated code.
>
> > > Roo keeps your code untouched. It stores the modifications elsewhere and
> > > merges those files at compilation-time.
>
> > --
> > You received this message because you are subscribed to the Google Groups
> > "Google Web Toolkit" group.
> > To post to this group, send email to google-we...@googlegroups.com.
> > To unsubscribe from this group, send email to

> > google-web-tool...@googlegroups.com<google-web-toolkit%2Bunsubs cr...@googlegroups.com>
> > .

[Joseph Li]

Think the whole point of having Roo + GWT is to easily generate pumping
codes like getters and settings and data transfer objects etc without too
much hand coding. I am not an expert on GWT nor Roo, but so far it looks
like it still need some work to iron out some strange issue, like the
generated scaffolding is not as robust as Grails and it doesn't run under
chrome but only runs on firefox.

But as far as the concept goes and I am experimenting it hoping to recommend
it to our next project to use GWT + Roo. I love Roo keep monitor the state
of the project and generate mechanical code on the side away from the src
thru aspect so I don't have to do it and it won't mess my src up. It doesn't
bother me much that it’s a code generator. Grails is actually a runtime code
generator as well and it is very popular, albeit too much black magic and no
decent tool support. I say as long as it doesn't mess with my src, I am good
with it.

Joseph

Jaroslav,

google-web-tool...@googlegroups.com.

[Marco De Angelis]

Thanks to everybody for sharing your opinion.

I think there is a way to keep your project code and roo code side-by-
side, as roo tries to keep the separation as tidy as possible through
AspectJ, secluded packages, etc.
I am not yet convinced, though, that keeping roo inside your project
is necessarely a good thing.

It may happen that some Entities are just byproducts of a
normalization process, and they just don't need Places, Activities,
Views, etc. Additionally, in the (positive) attempt to avoid 3rd party
crosscutting code, like spring IoC, guice or the like, you end up with
roo using a lot of default stuff that you cannot easily replace (e.g.
Activity.Display are not injected but are lazily built using a default
view).

Both GWT 2.1 and Spring Roo are pretty young, so we'll have to wait
and see where they're headed.