Announcement Announcement Module
Collapse
No announcement yet.
How to edit once-entered fields, entities etc using Roo shell Page Title Module
Move Remove Collapse
X
Conversation Detail Module
Collapse
  • Filter
  • Time
  • Show
Clear All
new posts

  • How to edit once-entered fields, entities etc using Roo shell

    There must be a way to edit once-entered fields or entities via the Roo shell.
    For example, say I typed in the fieldName as "temp" and later realized that it should be "temperature" ....how do I do correct that with the Roo shell
    Also I did try a few things to change a data type on a particular field...but the commands all said, the field exists(I thought it would overwrite)

  • #2
    Easiest and most natural way is to refactor the generated Java code. Roo will happily update all generated artifacts just as if it made the change itself. Remember that Roo is not simply a one-way code generator, but does round tripping. Alternatively, delete the field in your class (through the editor) and then issue a new shell command to create it correctly.

    Comment


    • #3
      Thanks Rod for the quick reply.

      Would like to suggest addition of a handy "field refactor" and an "entity refactor" command for the roo shell. Imho that should work even if the field has been tied to another entity as a FK/dependancy. When one begins using roo one would not do a "perform eclipse" until it is kinda stable and then these handy commands would work well(again, imho)

      Comment


      • #4
        I can see where you're coming from. Personally, however, I prefer to create a new Roo project in STS, wholly within the IDE, meaning I always have access to full refactoring capabilities.

        Comment


        • #5
          I could have used an "entity rename" command today after I made a typo in my entity name in the shell. But as Rod said, Roo will recreate all the generated artefacts when you refactor in STS.

          However, if you like, please raise a Jira request for these commands
          Cheers

          Comment


          • #6
            There also isn't much value in an exported script that has a typo followed by another script command with a correction. Better to refactor in Java and then correct the script so there's a single valid command.

            Comment


            • #7
              Originally posted by Rod Johnson View Post
              Easiest and most natural way is to refactor the generated Java code. Roo will happily update all generated artifacts just as if it made the change itself. Remember that Roo is not simply a one-way code generator, but does round tripping.
              The round tripping feature is indeed a beautiful thing and I agree that using the IDE is better for simple refactoring of code.

              However, I have a related issue in that I wanted to add the --testAutomatically flag to an entity I had created and have not found a way to do it retrospectively. Does anyone know if it's even possible?

              Comment


              • #8
                Try
                Code:
                test integration

                Comment


                • #9
                  Making corrections within Roo

                  So is this still the official policy? If you've set up a field or entity in roo and you want to change it later you should ignore the roo shell and use a Java IDE? That doesn't sound right to me?

                  I can sort of see your argument when the problem is nothing more than renaming a field refactoring the java may be simplest, but I'm trying figure out what options I need for a field set. Once I've created it I don't seem to have any means of changing them.

                  Comment


                  • #10
                    How to edit once-entered fields, entities etc using Roo shell

                    I agree with Ameelin. Insert should always be accompanied with edit. For my case for example I wanted to add a field by reference but since the class that I was referring to was not created I had to stop and create the other one (referred class) first. But then I couldn't go back to the referring class and put that field. Or am I missing the way to do it? Briefly, should fields of an entity be given to it the time the entity is defined (can they be given to it any time i prefer)? This all is without using sts or eclipse - plain roo shell.

                    Comment


                    • #11
                      Originally posted by Abiel View Post
                      I agree with Ameelin. Insert should always be accompanied with edit. For my case for example I wanted to add a field by reference but since the class that I was referring to was not created I had to stop and create the other one (referred class) first. But then I couldn't go back to the referring class and put that field. Or am I missing the way to do it? Briefly, should fields of an entity be given to it the time the entity is defined (can they be given to it any time i prefer)? This all is without using sts or eclipse - plain roo shell.
                      I also had the same filling before, but ..... now I'm agree with dev team.

                      I personally using roo from console, because in STS many commands simply do not work for the latest Roo RC1 build in my setup ... just no reaction, but in console everything OK ... but in parallele I have STS started, so I can work in IDE and console (I should make investigation and post Jira issue ... just find some time).

                      If you prefer to use only command line, but not IDE, it is also not a problem. Because, for sure, you are using some editor (vi, vim, textmate ... whatever) to work with files Roo have generated for you ....

                      So just open entity java class and simply delete line with wrong field definition ... repeat field command with correct params. Or, often you can just add appropriate annotation like @NotNull etc.

                      In conclusion: may be edit commands for fields and entities will be helpful (from start I also really wanted them and understand you ), but it are of least priority, IMHO.

                      Cheers.

                      Comment

                      Working...
                      X