Troubleshooting a bug with a WDK customization designed for creating S4M cuesheets

Every piece of TV content has an associated cuesheet indicating at what times different segments, such as commercials, voiceovers or show segments should be broadcast. These cuesheets would be fed into a broadcast trafficking system so the broadcast server would know what content to play at what timecodes.

In my current television broadcasting company, EMC Documentum is used to store the cuesheet information for an episode version by representing episodes as objects in the Documentum repository, and attaching the cuesheet data as attributes of the objects. I wrote a WDK (Documentum’s Web Development Kit) customization that displayed the cuesheet information as a panel available upon clicking the “i” icon of an object. Once the “i” icon was clicked, the customization would do some basic business logic checking to determine if a cuesheet for this episode should be allowed into S4M (some regions were not on Documentum yet so could not take advantage of our cuesheet customizations), and set the value of a true/false flag in the java class behind the JSP page. Then the user would be allowed to make changes to the cuesheet information. Afterwards, when the user wanted to save their changes, they could click on the OK button. This would trigger the onCommitChanges() method, which would check the value of the flag first before continuing. If the flag was set to not print the cuesheet, then the cuesheet file would not have been written to the monitored directory for S4M to import.

Over a weekend, this change was released to production, and seemed to work fine until suddenly cuesheets stopped being written to the monitored directory. After some careful examination of the code, I realized the flag was not being reset upon each view of the cuesheet WDK page. I then set the flag to reset upon every view of the cuesheet page, which resolved the issue.
The lesson learnt from this is that values set to members of the WDK code-behind class would be remembered throughout the life of the WDK session. Therefore class members should be set back to their default values upon every view of the WDK component, by adding initialization calls to the initControls() method.