One Stop Content Maintenance

scheduling.com continued to use the same content with its portal that it had previously used for its intranet static .html pages. The portal was bring that content into various gadgets and communities. For several reasons, we did not want to elimiate the intranet access to the page, but the formatting required for the two access paths was different.

It would have been infeasible maintain the same content in two different formats. The strategy we used to deal with the situation was to first convert the intranet pages to .asp (required for the Plumtree's hosted display mode anyway), then to move the page content onto .txt files such that the .asp pages contained the intranet formatting and include calls. The portal gadget then would reference only the .txt files. This avoided stylesheet collision, made formatting a non-issue, and let us format only a single .txt file to update both locations.

A problem that arose with the old intranet being accessible was that some users continued to use bookmarks to intranet pages without using the portal. We wanted users to use the portal to gain its ancillary benefits. The solution was to include code in appropriate intranet pages to force users into the portal. I culled the intranet log files for a list of pages frequently hit outside the portal, then into those I inserted this code that would detect whether the user was in the portal, and if not, it would convert their url into one that passed through the portal's gateway space in hosted display mode.

This worked to a point, but occasionally there were javascript refresh issues (infinite refreshing to the same page). To combat this irregularity, I put in additional javascript to detect this problem, then to abort after two tries.