Also have a look at the this forum discussion: http://forum.springsource.org/showthread.php?t=72378

The first installment of this task is now completed with the following changes available (as of revision 222):

1. Changed all jsp artifacts to jspx to allow for planned round tripping of jsp's.

2. Integrated Apache Tiles layout engine throughout the generated project.

3. Generated applications are now fully localized (current translation available in English and German)
This is achieved by appending ?lang=de to the URL. The language setting is stored in a cookie.

4. Generated applications are now theme aware.
This is achieved by appending ?theme=right to the URL. The theme setting is stored in a cookie.

A next step is to make language settings and theme settings available via a drop down box in the generated UI.

As mentioned in the thread linked below, here are the most common parts of the view I wish I could "freeze" or customize while still keeping the view in Roo-managed mode:

http://forum.springsource.org/showthread.php?t=80766

1) The commenting out or removal of a field I don't want displayed
2) Text box size changes
3) Field ordering on the page

These are the things that have repeatedly come up in experimentation and in early development of a real project. If I could make those customizations while Roo can still add new fields (or change them if the bean specs change), I feel like I could allow Roo to manage my views for much longer in the development process.

My suggestions are below. Over time I came to love the YAGNI principal, and many of my suggestions come from that principal.

1. By default, generate views that have no third-party dependencies, such as dojo. If someone wants dojo, let them opt-in. Looking at the website, I do not really see any value including dojo. This will enable me to plugin something like blueprint css and jquery without too much additional work. Removing dojo and cleaning up the markup negates any value I get from using ROO.
2. By default, generate minimalistic views without graphics, javascript and minimal CSS. There is no need for "style" attributes on elements. Again cleaning up the markup negates any value I get from ROO.
3. By default, allow the developer to specify the preferred language (such as english) and generate support only for that language. Then add additional commands ROO to add additional languages, if and when they are needed. Localization is rather complicated. We have found that we often need different views to deal with other languages.
4. By default, create components/tag/tiles for forms, lists and readonly views and include those in a view. This enables me to modify everything around the form of an entity while ROO can still keep it up to date if fields are added or removed from entities. For example, in ASP.NET we would use custom controls to this effect. This also means that the create and update forms can be reused - aka the DRY principal.
5. While I like that ROO generates ids and classes for elements in the views, I think its actually redundant to prefix them with web_mvc_jsp, roo and so forth. Its just more typing without much benefit.
6. While I like the idea of theme support, there is no need to generate support to switch between two themes in the beginning. Again, theming can be complex, so its best advised to introduce a convention for themes by having a themes folder under the styles folder. Provide a command to create a new theme, which could simply create a new folder in the themes folder with sample stylesheets and images etc. Create a default theme and stick to being minimalistic, since its likely to change and you don't want to create too much work for developers.
7. Since I use jquery a bit, it will be beneficial if I can generate javascript with a view. This may allow me to generate validation logic in Javascript based on constraints in the entity.
8. Try to generate views that are friendly for designers, like semantic markup. There is a lot of unessary markup being generated. Look at blueprint CSS for examples of simple forms with minimal markup.
9. I'd like to see support views for WAP, iPhone, JSON and XML so that a framework exists should someone connect using an iPhone, or an WAP enabled phone. JSON is great for AJAX like stuff. However, users should opt-in to these views and they shouldn't be generated by default.

@Werner Strydom: I agree with most of your points!

As per Ben's request in the post, this is a patch for something I did for DRY forms as per suggestion 4 of my comment.

Its my first attempt at contributing and I would appreciate feedback, if any.

I think it is time to close this issue given most of the suggestions are in place with the 1.1.x release train. The remaining suggestions are already in separate tickets and will be addressed over time (potentially also by external add-ons). If there are suggestions that have not been addressed or are already present in existing Jira tickets, please open separate tickets so we can review their feasibility.