Details

    • Type: Improvement Improvement
    • Status: Closed
    • Priority: Major Major
    • Resolution: Duplicate
    • Affects Version/s: None
    • Fix Version/s: 1.1.0.M1
    • Component/s: None
    • Labels:
      None

      Description

      As a lot of people have probably done before we also made our own code generation frameworks. Spring-roo has done this in a more consistent way, but there are a few things that would really make it stand out. Here are things that we tried to get from our code generation framework that Roo could benefit from in rough order of value:
      1) Usually when someone describes building a sample app for a tool they start off by drawing some entity diagram, and then go through 100 lines of xml config to implement the xml diagram. Roo has the same issue, except that it is 100 lines of roo script. Why not either:
      a) Provide a graphical modelling interface so that the drawing is the implementation (Modelling the problem = job done!!!)
      or
      b) Provide roo support from an existing modelling tool (e.g. handling the unwieldy but 'standard' XMI output from tools like Enterprise Architect).
      2) Provide screen modelling. Crud screens only get you so far, but at some point you will have screens based on composite fields
      2b) Provide graphical support for screen modelling. (2) is probably pretty hard to do from the command line, dragging and dropping fields from the entity model onto a screen would be nice.
      3) Conversion of an existing spreadsheet, database etc. into a roo project.
      4) Not sure if it makes a good Spring-roo story but data import from (3) is also possible to automate. Can be a value add story for an enterprise that has sent round spreadsheets for managers to fill in but now realises this wasn't such a flash idea.

      We have done all of these things internally and they did not take too long, but unfortunately they are proprietary. I may be able to assist based on my experience.

      Architecturally we had:
      Model Artifact -> Internal Meta Model
      Internal Meta Model + Screen Definitions -> 'Code' artifacts

      where Model Artifact could be any of XMI,XLS,CSV(with header),database, java classes etc.

      Roo could potentially be:
      Model Artifact -> Internal Meta Model
      Internal Meta Model + Screen Definitions <-> 'Code' artifacts

      1. EaToRooProject.roo
        2 kB
        whyBish
      2. survey.xmi
        47 kB
        whyBish
      3. survey.xml
        42 kB
        whyBish
      4. ZargoToRooProject.roo
        2 kB
        whyBish
      1. survey.png
        17 kB
      2. Survey.png
        9 kB

        Issue Links

          Activity

          Hide
          whyBish added a comment -

          Actually we also have an
          Internal Meta Model -> Internal Meta Model
          step so that we can modify the incoming db/spreadsheet etc. for normalisation etc. we also generate import/export classes for the data based on the transformation.

          Show
          whyBish added a comment - Actually we also have an Internal Meta Model -> Internal Meta Model step so that we can modify the incoming db/spreadsheet etc. for normalisation etc. we also generate import/export classes for the data based on the transformation.
          Hide
          whyBish added a comment -

          Someone suggested using EMF as the modelling framework.

          Show
          whyBish added a comment - Someone suggested using EMF as the modelling framework.
          Hide
          zqudlyba added a comment -

          SkywayBuilder and AndroMDA already do these, but guys at SpringSource have decided to go the scripting way. See reasoning here

          http://blog.springsource.com/2009/06/18/roo-part-3/

          Show
          zqudlyba added a comment - SkywayBuilder and AndroMDA already do these, but guys at SpringSource have decided to go the scripting way. See reasoning here http://blog.springsource.com/2009/06/18/roo-part-3/
          Hide
          whyBish added a comment -

          We've updated our tool to support argoUML as a frontend for roo generation. I'd love to make this into a roo component, if/when a component guide is done.

          Show
          whyBish added a comment - We've updated our tool to support argoUML as a frontend for roo generation. I'd love to make this into a roo component, if/when a component guide is done.
          Hide
          whyBish added a comment -

          We are also looking at digesting roo script, and outputting xmi for it. I think this would be a nice feature, you then have full roundtrip graphical modelling, EVEN IF someone just started from roo script command line.

          Show
          whyBish added a comment - We are also looking at digesting roo script, and outputting xmi for it. I think this would be a nice feature, you then have full roundtrip graphical modelling, EVEN IF someone just started from roo script command line.
          Hide
          Ben Alex added a comment -

          This request is very similar to ROO-46, so I'm going to close it so we can consolidate all the votes/ideas around GUI modelling features in a single issue (ROO-46). Thanks.

          Show
          Ben Alex added a comment - This request is very similar to ROO-46 , so I'm going to close it so we can consolidate all the votes/ideas around GUI modelling features in a single issue ( ROO-46 ). Thanks.

            People

            • Assignee:
              Ben Alex
              Reporter:
              whyBish
            • Votes:
              0 Vote for this issue
              Watchers:
              2 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved:

                Time Tracking

                Estimated:
                Original Estimate - 120d
                120d
                Remaining:
                Remaining Estimate - 120d
                120d
                Logged:
                Time Spent - Not Specified
                Not Specified