Converting from Clarify Desktop to Dovetail Agent (part 2)

This is the second installment of a series of posts on migrating applications/enhancements from the Clarify desktop application to Dovetail Agent features. The plan was for this post to cover converting Clarify Forms into Dovetail Agent/Admin pages. That is a great idea, but a very ambitious goal for a single post. I will be making a few posts along this line instead, trying to highlight the best practices and throw in a good amount of example code to help pave the way for such a conversion.


The example conversion of Employee Manager Utility (EMU) from a Clarify desktop integration to a new feature for Dovetail Agent and Dovetail Admin has a lot of possibilities for things to talk about. There are all kinds of controls used on the main form: a filtered grid, multiple tabs, checkboxes, text boxes, dropdowns, buttons, calendars… in other words, it’s not a simple project. Here is a screenshot of the main form and first tab of EMU that shows some of the detail:




Note the six other tabs on this form, and you get a sense of the complexity involved. From my previous experiences in these conversions, the amount of things that are going to be changed dictates that it is best to start from a clean slate, and add elements and code in small increments, and test thoroughly along the way.


The part of EMU is going to be used in Dovetail Admin, so looking at existing pages in Admin is the next step. As shown in the picture above, workgroups are the primary focus of EMU, and the page has to show existing workgroups and allow them to be updated. There are a number of pages in Dovetail Admin that perform the same function for other database objects. The Users/Employees page has the required layout.




There is a filter section at the top, a grid to show existing employees, and an are for editing a selected employee at the bottom. Since that matches well, it is the starting point for the conversion of EMU.


The first step is to create a new workgroup folder in Dovetail Admin, and then copy the 4 files from the user folder into the new workgroup folder. After changing the file names for the new object type, the files look like this:


  • workgroup.asp – the main page that has the filter fields, and frames for the grid and details
  • workgroups.asp – the details section for the workgroup that has all of the tabs
  • workgroup2.asp – the post-back page used to save any changes to the database
  • grid_workgroup.asp – the grid for displaying the existing workgroups


The next step is to go through the new pages and pare them down to the basics. It will be easier to incrementally add features and functionality back in than it will be to try to move things around. Changing a few things along the way helps. The filter fields are pared down to just a name filter, and all of the tabs that will be needed are set up as empty div elements. Changing the nav.htm file to add the link for Work Groups adds the ability to load the page as shown below. Here is the initial result of the cleanup process:




The code for what is shown above is pretty basic. The workgroups.asp and workgroup.asp (follow the links for the code) are all that is displayed, and grid_workgroup.asp will get loaded when the List link is clicked. Comparison to the original Clarify desktop design can now be made to see how this conversion is going. The page fundamentals are in place, but there are a lot of details to be filled in. The good news is that workgroups.asp and grid_workgroups.asp are finished at this point.


This post has laid the foundation for the next post. Getting an actual workgroup object to work with is the next goal, so the next post will cover putting some code behind the Add button and creating workgroup records.