One page for all sites… Or one page for each site

Question

I have an ongoing struggle (with myself :)) about the design and implementation of parts of the SharePoint system which I'm designing. I have included a diagram below. Effectively there are multiple sites that differ only by the content.

The structure of the sites and libraries (top 2 levels are sites):

Below is the page:

As you can see the page is one that shows an individual customer's document libraries. Logically, this places the page at the level of the individual customer's site.

However, given that the page is identical and points to identical libraries (in name, column layout, etc.) I am currently storing the page at the level of the top box in the diagram. This means that when I need to make changes to the layout I do not have to do it in multiple (1500!!) places.

However it is currently also bringing the challenge that I currently have, in that I am trying to programmatically change at run time 4 web parts on a page to show views of libraries that do not exist at the top level.

As I knock one error down another pops up. My question is more a design one really. Before I spend too much time trying to squash the errors am I going about this in the best way? How would you do it? All the sites currently are built programmatically and are "Blank Site"s containing "Document Library"s. There is no data in them at the moment so it wouldn't be a killer if I had to re-do them.

Thanks in advance for your input

Zak

Answer 1

I would go with a site definition that would contain all the document library and pages necessary for one customer. That way, through a module, you could provision the pages and you would not have to do some funky logic that would, at load time, change the links to the library.

If you deploy all the solution via a WSP package, you have 2 options :

1. Using a page layout and a content page based on this one (requires the publishing features to be enabled). Making changes to the page layout would update the content pages that are based on it.
2. Using a simple webpart page. You could not make changes through the UI, but if you need a new way to present the information, you could modify the page in the solution, redeploy it, and if the associated module was not unghosted, the changes will be pushed down to every page of every sites based on the site definition.

Maybe the publishing infrastructure adds a lot of overhead for that simple requirement, so my choice would probably be #2 if you're not making a lot of changes to the base page. If you want to make frequent changes, I would go with the option #1. For both options, I think it would be a lot easier and you would gain in performance, without the need to change the document library links dynamically on the load time...