Global and local information in one page

I recently had to solve a challenging requirement for a MOSS 2007 site we were building a prototype for.

The scenario

A central organisation creates articles (using a complex approval workflow). Local organisations shall be able to add local information to these articles (using a simple approval workflow). Only additions are allowed at specific places in the article - the global information may not be overridden.

Now, users of the site should by default see the global article. When they select a local branch however, the same information shall be visible with the local information added to the page.

The solution

Our first thought was to use variations. But it didn't feel right. Not enough control, and we might want to use variations for language later on.

Instead, we chose to have one global site that contained all global articles. Another site contained all local organisations, and below each of these we had a container with local articles. However, it was imperative that we did not duplicate any content - that's quite simply against my principles.

Global articles used the content type GlobalArticle while the local articles used the content type LocalArticle. Each LocalArticle contains a reference to a GlobalArticle. The LocalArticle does not contain the fields that exist in GlobalArticle, but instead contains a field for each place where local content is allowed.

The PageLayout used for rendering a LocalArticle looks up the GlobalArticle and renders its information in a read-only mode. In other aspects, it works just like any other PageLayout, allowing an editor to modify the local content as usual.

The appeal of this solution is that we use standard MOSS functionality almost all the way, with only a minimal look-up in the local PageLayout. We support standard MOSS page workflows. Global content is automatically updated on the local site without we having to do anything.



Solution details

Some additional challenges existed though. We wanted to make a local article available automatically when the first global article was published. Also, the article context should remain on the user screen even when the user switched between the global to a local view, and between different local views.

The components we needed:

• A business service that returns the local sites
  Simply list all sites in the "local sites" site.


• An event that listens to changes in the global article list
  When an article is published (or unpublished) it checks whether a local copy exists in each local site. If not, it creates and publishes a LocalArticle in the local store, with a reference to the recently published GlobalArticle.


• A little user component letting the user switch to a local context
  The important thing here was to still remain on the same article. Quite easy thanks to the structure we used.

That's basically it. Might be worth mentioning that the user interface was designed to clearly show what information was global and what was local by use of both icons and color.