A Tale of Refactoring


A few weeks from now, I was in a big project that had the request for a feature to spot changes in two records in an entity, and present them in a human readable way.

The solution was a simple project with one screen that compared two records and show the results on a popup. It was a cool project. I had to develop an extension and build a an algorithm to match the differences and take care of the process, but that was not all of it.

Our Manager was so happy with the solution, that after I finished the task, he asked me to build a reusable tool from that. I was not expecting this…. It was a single eSpace application and that’s no way to build a reusable solution that can be further extended.

I put up a list of stuff that I needed to refactor so I could negotiate the needed time with him:

  1. The compare actions and database entities needed to be moved to another eSpace that had no dependency with the current one;
  2. The homepage was quite cluttered so I needed to leave some information on the homepage and move the compare functionality to another screen;
  3. The buttons and popup’s that show the result of the comparison will be used on another screen, so it is a good idea to have a way to reuse them;

So, the challenge is now to refactor the application in order to accommodate the necessary changes ( you can find the beginning and the end code in attach ).

Refactoring Entities and Actions

  1. Moving actions and entities to another eSpace

There’s a number of ways you can move entities and actions to a different eSpace, and they can get you to a big load of work, or they can be quite easy to do. I believe that I’ve found a way to do it in a simple and cofortable way. These were my moves:

1.1.  Create a new eSpace

The actions and entities you will be moving will reside in a new eSpace, so, you need to create a new eSpace for them. The link I left here takes you to Service Studio Help if you don’t know how to do it;

1.2. Move actions to the new eSpace

With the new eSpace in place, you can copy the actions and the entities from the original eSpace and paste them in the new one. This is not a physical move, because you won’t be moving the entities and their data to the new eSpace. We’ll take care of that later;

1.3. Publish the new eSpace

After copying the items, and before publishing, make sure all actions are exposed  and then publish the new  eSpace;

Figure 1: Exposed entity

1.4.  Delete the original entities and actions

In the original eSpace, delete the actions and entities you’ve copied. Don’t bother with the TrueChange errors. Will fix that later;

1.5. Reference entities and actions

Now that you’ve deleted the actions and entities from the original eSpace, you need to reference the ones you’ve pasted into the new one. See how to do it here;

Figure 2: Original eSpace data structure before moving entities

Figure 3: Original eSpace data structure after referencing the entities in destination eSpace

You shouldn’t have any errors now and everything should be working fine.

As said before, copying entities does not move data.  Moving database entities in this manner will have the consequence of data loss because only the data model will be copied and not the data. In order to prevent data loss is necessary to export the data on the origin eSpace before deleting the entities and then do a bootstrap on the destination eSpace for that data. To do this bootstrap process it’s important to validate the data consistency to ensure the absence of problems. It’s also recommended to purge the data of an entity before deleting the entity otherwise the data will remain in the database, although not accessible, and can cause unexpected issues in the future, usually with

foreign keys.

Refactoring Web Screens and Web Blocks

  1. Split the functionalities from the Homepage to a new  Web Screen

2.1 .Create a new Web Screen

This is the screen that will contain some of the functionality that is currently in the home page. We will be moving some content from the homepage to here;

2.2. Move actions to the new web screen

Before moving the functionalities, move to the new Web Screen the actions that will be needed, including auxiliary actions;

2.3. Move the functionalities to the new Web Screen;

Deal with unwanted content or actions that could remain in either of the Web Screens and fix errors and warnings, if any.

Be careful because it may also be necessary to move or copy some styles or JavaScript functions to the new screen;

Figure 4: Homepage before changes (notice all functionality visible)


Figure 5: The Homepage after the changes (clean and simple)

Figure 6: The new Web Screen with the moved functionality (the one that was in the home page)

  1. Move buttons from the Homepage to a new Web Block so that they can be reused

3.1. Create a new Web Block;

This will be the web block that will hold the functionality that will be reused;

3.2. Move actions to the new web block

Before moving the functionalities copy or move to the new Web Block the actions that will be needed including auxiliary actions;

3.3. Move the functionalities from the Web Screen to the Web Block

Deal with unwanted content or actions that could be remaining in the Web Screen or in the Web Block and fix errors and warnings, if any.

It may also be necessary to move or copy some styles or JavaScript functions;

Figure 7: The new Web Block in Service Studio with the Buttons

Figure 8: The new Web Screen including the new Web Block

This was my Tale of Refactoring! Hope it helps you somehow!

Can you share the way you do it in your projects?

Nice work and nice article, Nuno!