Roo customization - a major issue?

[delgad9]

I don't think anybody is hiding the code at all... After worked with Roo for more than a year and implemented several successful projects using it, I can tell you that ITDs are one the great features and differentiators coming with Roo.

As you continue learning the tool, you will find the convenience of hiding boiler plate code with aspects is a very-very effective and productive developing strategy.

Understanding and customizing Roo is not that hard. Books and tutorials at all levels is what is needed: beginners, intermediate and advance to show how to use this wonderful tool. Somehow the beginners level is partially covered but not the other ones.

On the other hand: To me your story is very eloquent and symptomatic -based in your description: A well seasoned software servicing organization -with an army of experienced developers- having trouble leveraging Roo. If you high-end IT people are having trouble understanding Roo what is going to happen to the rest of the community?.

Something needs to be done about it. I am open to suggestions

B. Roogards
jD

[jbbarquero]

Actually, Roo doesn't hide any code, STS in its default configuration does.

You can customize it using the Filters option (Hide/Show generated Spring Roo ITDs)

Furthermore, Roo only generates code. For doing so, it uses some technology (JPA, Aspects, Spring MVC, Spring security...)

The main problems that you're going to face is the ones related with such technologies.

So your challenge is to master these technologies.

Of course, Roo has its own limitations (mvn multi-modules not supported, use of Dojo instead of JQuery [provided you prefer the latter technology], lack of options in the commands to add extra JPA annotations)

But at the the end, the code is easily configurable because of the use of annotations and compact code in the generated views.

[Apologies for the response, but we failed with Roo a year ago due to the exposed above, and I wasn't be able to explain this to my responsibles at that moment]

[delgad9]

Just a couple of quick points on the following...

Of course, Roo has its own limitations (mvn multi-modules not supported, use of Dojo instead of JQuery [provided you prefer the latter technology], lack of options in the commands to add extra JPA annotations)

1) Typically you need multi-modules because you want to deploy same back-end with for using it with multiple clients... My article at http://pragmatikroo.blogspot.com/201...-multiple.html describes how to accomplish such using multiple view resolvers -instead of using -mvn multi-modules- on the same web server. No need to mess with mvn at all.
2) Roo is pretty much unique in the sense that its WEB-MVC can be customized to support multiple js libraries, as described in my article: http://pragmatikroo.blogspot.com/201...ve-jquery.html. Here I describe a PoC -actually is an add-on now- for migrating native Roo clients and convert them for using jQuery. I am using same addon for creating mobile web apps, as described here http://pragmatikroo.blogspot.com/201...es-mobile.html.


B. Roogards
jD

[jbbarquero]

Thanks for your articles.

Actually I need multi-module in order to create an EAR for deploying it in WebSphere Application Server

The typical structure is a parent for the project, and at least one module for the web application (WAR), another for the EAR and maybe others for JARs containing the business classes (it depends on whether or not the WAR contains the business logic which highly depends on if there are previous JAR with common business logic)

[delgad9]

I have another article suggestion about that too...
http://kb.vmware.com/selfservice/search.do?cmd=displayKC&docType=kc&externalId=2001 172

Article is really great... BTW, By deploying Spring based app on different web servers than Tomcat or TCS creates unnecessary overlapping technology stacks. Consequently waste of memory and slowness. Probably you know that.

Roogards
jD

[emil2010]

Hi,

Ive been using Roo now for 3 years or thereabouts, and in that time Ive learned a lot on how to customize Roo generated code.

I think of Roo as my helper to create the backbone of the application. When that is about done I go to phase 2 in the project, which is adding my own changes to the project, customizing it so that users only see their entries and not entries from other users etc.

I use the session for that and give each login a new applicationID. So I turn of Roo when I start phase 2, because I need to change the roo code quite extensively.

The only thing I havnt really mastered is dual dropdown lists, that is populating a second dropdown list filtered by the id you select in the first list.

Regards,
Emil

[jbbarquero]

Regarding deploying Spring applications in WAS, it comes out the boilerplate of profiling. In order to use something like that publib.boulder.ibm.com/infocenter/wasinfo/v7r0/index.jsp?topic=/com.ibm.websphere.nd.multiplatform.doc/info/ae/ae/cspr_data_access_tran1.html or selecting the appropriate JSP/Servlets dependencies, we need to have a lot of work in the pom.xml, appCtx.xml and so on.

Regarding the 2nd phase approach, we haven't achieved a standard process to do so yet. But we're still trying to find a method that fits with our development process (or even to improve this process with the available tools and the ones that must to come, as wavemaker, for instance)

[delgad9]

@Emil2010,

You can review my article...

at http://viralpatel.net/blogs/2011/01/...ail-forms.html for you filtered drop-down list.

The code described can be easily extrapolated for using lists instead of grids.


B. Roogrards
jD

[oceanfront]

We have just finished our first roo based app. Customizing things went surprisingly smooth at the java level. What I would like to see is what tools / workflow other roo developers are using to move the designers html/css layouts into a tiles/jspx theme and layout for use in a roo based project.

[delgad9]

@oceanfront,

I am very glad learning on your successful Roo experience...
I think the Roo customization - a major issue is becoming more a myth by the day.


B. Roogards
jD