Sunday 9 September 2007

Blending publishing/collaboration functionality in SharePoint

Most often when creating SharePoint solutions, the requirements often map fairly well to one of the out-of-the-box site definitions which can be used to create new sites. If we're creating heavily-branded internet/intranet sites (WCM sites), we'll probably start with the 'publishing site' template. If we are deploying SharePoint in a document management/collaboration scenario, we'll probably start with the 'team site' template, and so on. Where it gets interesting it when the project requirements effectively have a mix of this functionality. Characteristics of such a site might include:

  • site has completely bespoke look and feel/navigation
  • users will work with files stored in document libraries
  • site templates or definitions are used to create several sites with the same content/functionality
  • custom workflow is used to support a business process (other than standard content publishing), perhaps with InfoPath forms

Such requirements present a few challenges, and a current project of mine fits into this category. At a high level, one consideration is that site users will also use 'system' pages provided by SharePoint in many scenarios (e.g. working with document libraries/lists, workflow etc.) and this doesn't happen in most WCM sites. This can lead to situations where there is a disparity between the look and feel of the 'published view' of the website and the 'system' areas. I don't intend to provide answers to all the issues here, but I do want to discuss a few as some food for thought. I'll probably revisit this post at the end of the project and provide a better insight into the issues and solutions, but for now let's cover some high-level decisions:

 

Approach for master page development

Options for starting development here include:

  • Using a 'minimal master page' from MSDN or Heather Solomon
  • Modifying a copy of default.master (good starting point for customized team sites)
  • Modifying a copy of blueband.master (good starting point for WCM sites)

Partly this decision depends on where you are heading. Since the aim in my project is for formatting to be controlled by CSS rather than layout tables, starting with a minimal master page makes more sense (the shipped page layouts use tables). This is an interesting area since there's a lot of rework to be done to eliminate tables in a mixed publishing/collab site (and in fact it often won't be possible to eliminate them completely), and for me the benefit is debatable. Certainly all the 'system' pages which site users will be exposed to use layout tables, so I'm not sure how much is gained by only having some pages using CSS for layout.

Other things to consider here are the usual questions of how to factor responsibility of content items between the master page and page layouts, how to define content types etc., but these are standard decisions in WCM site development so I won't cover them here.

 

Use of Content Editor web parts vs publishing RichHtmlField controls

Most folks in WCM development know there is an overlap in functionality provided by the Content Editor web part and the RichHtmlField control in the Microsoft.SharePoint.Publishing.WebControls namespace, i.e. they can both be used to enter page content such as text/images. However it's important to consider the differences - the RichHtmlField control stores it's content in a column of the list item for the page, whereas the CEWP is a web part and thus stores content in the web part storage architecture. This is important, since if deployment to a different environment is in your project plan or ongoing architecture, things will likely be simpler if you use the field control, since this content will then travel with the page properly.

Additionally, there are some URL fix-up issues with using the CEWP across different environments, as documented in the HawaiianAir.com write up.

In summary, I'd recommend considering the CEWP as a means of entering content in non-publishing SharePoint sites only. 

 

Use of collaboration web parts - in layouts or in WebPartZones?

In a similar vein, since we are mixing the collaboration features into our site we are likely to need to use certain web parts which we wouldn't in a straight WCM site. In our situation the ListViewWebPart is fairly key to some areas, and is used as a means of allowing users to work with different lists from one page. The first decision here is whether the page layouts should include web parts directly (by adding them in SharePoint Designer), or just web part zones to which the individual parts would be added later through the browser. In most WCM scenarios I prefer to add web parts directly to page layouts since they will not be customized/personalized by end users (the main usage scenario for web part zones), and when web part zones are used, again the web part config is not stored in the page which can make deployment more complex. Using the other approach of adding directly from SPD, config is stored in the actual HTML markup of the page and so travels with the page layout itself.

However! The ListViewWebPart has some quirks which means it isn't always possible to use directly from the page layout. Specifically, it is only possible to configure the part to consume a list from the current web, and in the case of a publishing page layout, this means the root web since this is where the master page gallery is stored. Since our lists are stored in a child web, this is problematic - the other solution of using a DataView also had issues. Additionally, the ListViewWebPart configuration stores values specific to it's location, meaning the config XML is not very portable (i.e. export web part definition, modify, use). I'd like to think it would be possible with time to work out exactly which IDs do need to be changed, but alas we don't have time on this project.

As a result, using the ListViewWebPart in a web part zone is actually the best solution in these circumstances as far as I can see. We'll have an extra few steps at deployment, but this will take less time than the alternatives it appears.

 

Look and feel of system pages

As mentioned earlier, for a mixed WCM/collaboration site there can be a disparity of the look and feel of the main pages of the site and the 'system' pages users will see, i.e. pages from the '_layouts' directory. Note this happens even if both the site and system master page is set to point at your custom master page, since these pages are set to use 'application.master' (also on the filesystem in '_layouts') which neither of these properties affect. Sure it would be possible to simply replace 'application.master' with your own version, but that's not an elegant solution and would probably be unsupported. Unfortunately it seems that the architecture doesn't provide an easy way to change the master page used by '_layouts' pages - you have to go a level deeper to explore ways of doing this. Many .Net 2.0 developers will know it's possible to switch a master page dynamically in .Net, and to be fair this is what SharePoint does with the maser pages stored in the master page gallery anyway. I'm not aware of a truly elegant solution to this problem, but this discussion on Serge van den Oever's blog presents a viable approach using this technique. 

 

So those are some of the issues to consider. There are certainly others, including navigation, CSS customization of standard styles (to ensure collaboration web parts integrate well with your look and feel), and possibly the choice of authentication mechanism. I'll cover these and any others which arise in an upcoming post.

8 comments:

Anonymous said...

Re: Look and feel of system pages - I'd a look at this about 6 months back, and ended up using an HTTP Module to modify pages that were using the application.master page. It worked well, though unfortunately the blog I got it from lost its post a while back.

Anyway, I found that other folks had posted similar techniques...

http://www.novolocus.com/display.php?id=452

One thing to note - I did find that the application master pages had a couple of extra required placeholders compared to a 'normal' master page.

Eric Murriguez said...

Great post! I'm managing a large MOSS 2007-based extranet, and I recently have run into this scenario/problem. We have our site divided roughly into "public" sites that use a customized publishing site template, and private team sites that use the team site templates.

I recently decided to create a hybrid by starting with a team site template, but activating the publishing feature and using a customized master page with a different breadcrumb style.

This seems to work fine at first glance, but when I save it as a site template and then create new sites from this template, everyone who is not in the Site Collection Administrators group gets the following error:

"List does not exist

The page you selected contains a list that does not exist. It may have been deleted by another user. "

Interestingly, the current navigation also shows up simply with "Error" as the only link, but once you click on it for the first time, it seems to "fix" itself.

So, I noticed that if I rolled back the custom master page, it seemed to work fine, and I thought that maybe this was a master page issue. But after reading your post, it sounds like it may be a bit more complicated than that....

I will be keeping my eye on your blog, and, naturally, if what I'm describing sounds like an obvious problem/solution, let me know!

Cheers,

Eric

Chris O'Brien said...

Eric,

Hmm that _is_ an interesting one. The first thing I wonder though, is if by 'site template' you really do mean site template and not site definition? If you do, I also wonder if this could be related to the fact that site templates aren't officially supported for publishing sites. You may have noticed that the 'Save site as template' link disappears when you enable the publishing feature, and I believe this is because there are some publishing capabilities which can't currently be saved into the .stp file.

Curious that it's OK for site collection admins though. Have you tried playing with the permissions of the list to see if that makes a difference?

Cheers,

Chris.

Chris O'Brien said...

Eric,

Hmm that _is_ an interesting one. The first thing I wonder though, is if by 'site template' you really do mean site template and not site definition? If you do, I also wonder if this could be related to the fact that site templates aren't officially supported for publishing sites. You may have noticed that the 'Save site as template' link disappears when you enable the publishing feature, and I believe this is because there are some publishing capabilities which can't currently be saved into the .stp file.

Curious that it's OK for site collection admins though. Have you tried playing with the permissions of the list to see if that makes a difference?

Cheers,

Chris.

Eric Murriguez said...

Chris, thanks for getting back so quickly. I apologize for sloppiness with the language -- I'm pretty new to MOSS (using it since about May of this year!) and am just scratching the surface of the customization options. I have a C#.NET background but am pretty new to ASP.NET and of course learning the SharePoint object model on top of that...rapid catch up time! In other words, a desktop guy that has been forced to become a web guy :)

Anyway, I actually figured out this particular problem -- the master page was pending approval and not published. Gotcha! I hang my head in shame...

But, you are right -- there is no option to save the site as a template, but I just add the "_layouts/savetmpl.aspx" to the site that I want to save as a template.

So, what I have done, is basically: 1) start with a publishing site, 2) activate the collaboration feature(s), 3) apply the custom master page, and 4) save as a template as stated above.

However, as you say, I'm sort of cheating the system by appending the savetmpl.aspx -- what this has done is create a custom tab that says "PublishingSiteTemplate" on the "Create Site" (/newsbweb.aspx) pages. And when I create the site from this template, the current nav is initially corrupt (says "Error"), but when I go into the master page setting and reset the master page, it fixes the problem and the site seems to be fine.

Which leads me to my next quest -- how to edit the tabs or xml generating the tabs on that /newsbweb.aspx page.

Unknown said...

The main problem I experienced with converting BlueTabs to the required look and feel was all the "overhead" that Microsoft includes in it's MasterPages. Rebuilding starting with the Minimum Master presented a much cleaner and streamlined Master Page to maintain.

I also 'cheated' by using Site Templates in a Publishing site, this was functional for a time, but then strange errors were created, the Content Type of the default Welcome page for all new sites were set to "Page" and other odd things that required additional work when creating new sites.

Matthieu Couque said...

It's maybe late to post a comment on that but i'm working on a publishing master page.
I can't manage to display a richHtmlField, i can use htmlEditor and InputFormTextBox but both can be edited whitout be in editing mode.
So I'd like to now if there is a solution or if i need to develop my own WebPart/Control.

Thanks

Chris O'Brien said...

@Potzi,

You don't need to develop a custom web part/control - the RichHtmlField is the control to use for Web Content Management templates in SharePoint. However, you need to ensure your page uses a content type which has appropriate fields to store the data. If editing a page layout, SharePoint Designer helps you out by adding controls to the toolbox which can simply be dragged onto the template HTML - this will ensure you get the markup right.

HTH,

Chris.