Spring Roo
  1. Spring Roo
  2. ROO-8

Review templating approach to be more flexible and allow better custom branding of generated applications

    Details

    • Type: Improvement Improvement
    • Status: Resolved
    • Priority: Major Major
    • Resolution: Complete
    • Affects Version/s: 1.0.0.A2
    • Fix Version/s: 1.1.2.RELEASE
    • Component/s: WEB MVC
    • Labels:
      None

      Description

      The generated view artifacts do currently allow for customization of the generated application via CSS, the header.jsp and the footer.jsp but there are some opportunities to simplify end-user branding.

        Issue Links

          Activity

          Hide
          Marcel Overdijk added a comment -

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

          Show
          Marcel Overdijk added a comment - Also have a look at the this forum discussion: http://forum.springsource.org/showthread.php?t=72378
          Hide
          Stefan Schmidt added a comment -

          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.

          Show
          Stefan Schmidt added a comment - 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.
          Hide
          Mike J added a comment -

          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.

          Show
          Mike J added a comment - 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.
          Hide
          Werner Strydom added a comment -

          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.
          Show
          Werner Strydom added a comment - My suggestions are below. Over time I came to love the YAGNI principal, and many of my suggestions come from that principal. 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. 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. 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. 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. 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. 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. 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. 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. 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.
          Hide
          Marcel Overdijk added a comment -

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

          Show
          Marcel Overdijk added a comment - @Werner Strydom: I agree with most of your points!
          Hide
          Werner Strydom added a comment -

          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.

          Show
          Werner Strydom added a comment - 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.
          Hide
          Stefan Schmidt added a comment -

          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.

          Show
          Stefan Schmidt added a comment - 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.

            People

            • Assignee:
              Stefan Schmidt
              Reporter:
              Stefan Schmidt
            • Votes:
              38 Vote for this issue
              Watchers:
              24 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved: