Cincom VisualWorks Web Toolkit Tutorial : Refactoring the J2EE Solution

Refactoring the J2EE Solution

In the previous lesson, we reduced the number of times the Toyz class was instanciated from three separate times to just one. We also created a page that displays a list of employees who have taken a particular course. Believe it or not, there is a bug in that page and we need to refactor our code to fix it.

In this lesson, we will refactor our code to fix the bug in the page that lists employees who have taken a particular course. This will involve making changes to our classes.

1. If VisualWorks is not already running, please start running it now, load the Web Toolkit parcel and start a Wave HTTP server. You should also file in the code from Toyz Inc J6.

2. Sign on as Carl and proceed to the page that displays a list of employees who have taken a particular course. Go ahead. Try it a few times. Notice the results.

Figure 1. First time through - the drop-down list works perfectly

Figure 2. Second time through - results look fine but the drop-down list has doubled

Figure 3. Third time through - results have doubled and the drop-down list has tripled

What is going on with these crazy results?

Actually, nothing. In fact, the code is working just as it should have and is a verifcation that we are indeed re-using our session object of the Toyz class. In other words, it proves that the same instance of Toyz is being used in our application. Here's why.

Figure 4. The initialize method of the Toyz class

When we create an instance of the Toyz class, we create an instance of the FileStuff class.

Figure 5. The initialize method of the FileStuff class

When we create an instance of the FileStuff class, we create sorted collections for our instance variables of courses, employees and xrefs.

Figure 6. The getCourses method of the FileStuff class

Note that each time we execute this method, we keep adding to the collection. Since the session object of our Toyz class is the same instance of the original object, the list of courses is appended to the list that already exists. This explains why each time you submit the form on this page, the list keeps getting longer and longer.

This is also true for the getXrefs method and explains why the list of courses displayed keeps getting longer each time you submit the form.

How do we fix this?

One fix would be not to use a session variable for our instance of the Toyz class. If we wrote this page for phase 5 or lower, it would work. But the drawback would be that the web server would cause Smalltalk to work very hard by always creating instances of our classes. This is something we wanted to avoid.

The desired fix would be to modify our methods.

Clone the getCouses method of FileStuff to getCoursesFromFile
Change the getCourses method to check if the courses instance variable (collection initialized in the new method) is empty
If empty, load courses from the file
If not empty, just return the courses variable
Do the same for the getXrefs method and the xrefs instance variable
Do the same for the getEmplolyees method and the employees instance variable

3. Remove the ToyzInc category of classes and file in the code from Toyz Inc Refactored 6. Since all the "refactoring work" has been done on the custom objects, we can simply retest our pages without any further modifcation to them.

Figure 7. The drop-down list after several iterations of submitting this form

Congratulations! Phase 6 of the TEACH application is complete

Our code (application) is now more efficient since we are able to reuse obects in the web environment just as we would have in a typical Smalltalk GUI application.

You now should be able to:

Make changes to web pages by making changes to custom objects in the Smalltalk image