Announcement Announcement Module
Collapse
No announcement yet.
Roo customization - a major issue? Page Title Module
Move Remove Collapse
X
Conversation Detail Module
Collapse
  • Filter
  • Time
  • Show
Clear All
new posts

  • Roo customization - a major issue?

    I started looking Roo recently. I have very rich experience in J2EE but has Beginner knowledge in Spring and Hibernate.

    I really find difficult to customize the roo generated code. I have seen some documentation where UI look and feel can be modified.

    Alteast I couldn't find documentations related to my question

    Here are my questions:

    1) How to customize or modify the jsps?

    2) How do I modify or create my own controller while rest of the code are Roo generated?

    3) How can I customize the finders?

    4) How can I do Internationalization - i18n?

    5) How can I create search or list screen which brings data from more than one table (joins)

  • #2
    Well you're our target audience, so I'll do my best to answer your questions:

    Originally posted by nprabakaran View Post
    1) How to customize or modify the jsps?
    That's quite a broad question; what do you want to do specifically?

    Originally posted by nprabakaran View Post
    2) How do I modify or create my own controller while rest of the code are Roo generated?
    Roo can generate (and subsequently maintain) Spring MVC controllers for some/all of your domain entities via the "web mvc scaffold" and "web mvc all" commands. You can customise these controllers either by adding new methods to them or by pushing some or all of the methods from the ITDs into the controllers' .java files.

    Roo can also generate (but not maintain) a new controller via the "web mvc controller" command. It's up to you to code this controller as required (see the Spring MVC doco for details).

    Originally posted by nprabakaran View Post
    3) How can I customize the finders?
    You can write your own finders as static methods in whatever class you like, or you can ask Roo to generate finders for you using the "finder add" command. This puts a finder into the "_Roo_Finder" ITD, from where you can push it in and customise it as desired.

    Originally posted by nprabakaran View Post
    4) How can I do Internationalization - i18n?
    Roo already generates internationalized applications, with English as the default language. To add another supported language to a Roo app, simply use the "web mvc language" command. Any language can be supported as long as the Roo team or someone in the community writes an addon (using the "addon create i18n" command).

    Originally posted by nprabakaran View Post
    5) How can I create search or list screen which brings data from more than one table (joins)
    Like with most JPA apps, Roo's presentation layer works with a rich domain model rather than concerning itself directly with persistence-related concerns such as tables. You can show fields from more than one entity by writing a view (e.g. a JSP) that navigates the associations from one entity to another. These will be lazily loaded by default (Roo loads an OpenEntityManagerInViewFilter via web.xml), so you might want to tune the relevant finders to fetch some parts of your object graph eagerly. How and when to do this is getting outside the scope of this forum, however.

    I hope this answers your questions.

    Comment


    • #3
      Very Nice! Thanks - thats a very quick reply. I will try out based on your suggestion and get back.

      I want to tell something to you "Andrew Swan".

      I work for one of the largest software servicing company in the world. One of our team wanted to introduce Roo through out the organization for J2EE app development. The group validated Roo and Skyway. They concluded that Roo's customization is very difficult or atleast lacks enough documentation ; then for skyway they concluded that its introduces dependency on skyway plus it is not purely open source. Finally they created new spring based code generator from scratch in 5 months and that rocks throughout the org.


      I strongly suggest Spring Roo team to concentrate more on releasing step by step documentation for customization with multiple scenarios. This will make Roo more popular.

      Comment


      • #4
        Thanks for the feedback

        Originally posted by nprabakaran View Post
        I work for one of the largest software servicing company in the world. One of our team wanted to introduce Roo through out the organization for J2EE app development. The group validated Roo and Skyway. They concluded that Roo's customization is very difficult or atleast lacks enough documentation ; then for skyway they concluded that its introduces dependency on skyway plus it is not purely open source. Finally they created new spring based code generator from scratch in 5 months and that rocks throughout the org.
        Interesting! Not many shops would go the route of writing their own code generator. How does its feature set compare with Roo, e.g. how does it support round-tripping, is it extensible via addons/plugins, etc? I understand if the details are commercially sensitive. By the way, the Roo 1.2 release will add a lot of scope for customisation, particularly in the area of application architecture.

        Originally posted by nprabakaran View Post
        I strongly suggest Spring Roo team to concentrate more on releasing step by step documentation for customization with multiple scenarios. This will make Roo more popular.
        Thanks for the feedback, it's always useful. As you can appreciate, we're a busy lot on the Roo team; what parts of the existing documentation do you think are most urgently in need of improvement?

        P.S. You can call me "Andrew"...

        Comment


        • #5
          @nprabakaran,

          I work for the smallest software servicing org. in the world...
          I was able to accomplish the following Java web development projects using Roo-
          This is the link http://pragmatikroo.blogspot.com/201...ductivity.html- all by myself. All the projects are Roo based just lightly tweaking the UI part.

          B. Roogards
          jD

          Comment


          • #6
            Excellent jD!

            If your work is for community, can you share the source of your work and if there is any documentation on top of it?

            Comment


            • #7
              @nprabakaran,

              Yes, I totally work for the SR community...
              I am currently on the quest of (a) compan(y/ies) that sponsor my work. This will allow me to release my SR solutions on a sustainable and responsible way. I've contacted book houses for publishing my work too.

              If you have chance; I invite you to review my blog site, where you can find solutions on Roo questions very hard to find in other place.

              I am willing to share in win-win scenario.

              B. Roogards
              jD

              Comment


              • #8
                thanks jD!

                Andrew to answer some your questions - yes its commercially sensitive. Its not as extensible as Roo but work is good. We cannot compare the extensibility with Roo because Roo is designed for a greater cause.

                Comment


                • #9
                  @nprabakaran and to whom it might be concern,

                  Maybe in the near future your org. would like to consider Roo again... I believe you guys are more interested in developing business stuff than infrastructure stuff.

                  Bottom line: Roo is a great technology. What is urgently needed are Roo advocates that create documentation to show the community how to move a CRUD Roo projects to a real production one. I already created a bunch of showcases -based on unanswered questions from the forum and open Roo Jira tickets- for helping the community.

                  It is sad to see potential users walking away because they can't satisfy their requirements with Roo. I wish there would be incentives for releasing my solutions.

                  B. Roogards
                  jD

                  Comment


                  • #10
                    Customization and ease of understanding is the key aspect. You should be able to customize things easily and also Roo or Roo generated code should use less annotation or it should not hide much code. When you are not hiding the code, its easy to customize.

                    I am getting very interested in Roo. Soon I would also like to contribute to this project. I m in learning phase now!

                    Comment


                    • #11
                      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

                      Comment


                      • #12
                        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]

                        Comment


                        • #13
                          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

                          Comment


                          • #14
                            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)

                            Comment


                            • #15
                              I have another article suggestion about that too...
                              http://kb.vmware.com/selfservice/sea...rnalId=2001172

                              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

                              Comment

                              Working...
                              X