Hi Marco, I'm inclined to go with approach #2 as well for the same reasons you've mentioned below.
BR, ~A On Fri, Jun 18, 2010 at 4:20 PM, Marco De Angelis < [email protected]> wrote: > 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. > > -- > You received this message because you are subscribed to the Google Groups > "Google Web Toolkit" group. > To post to this group, send email to [email protected]. > To unsubscribe from this group, send email to > [email protected]<google-web-toolkit%[email protected]> > . > For more options, visit this group at > http://groups.google.com/group/google-web-toolkit?hl=en. > > -- You received this message because you are subscribed to the Google Groups "Google Web Toolkit" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/google-web-toolkit?hl=en.
