• http://blogs.msdn.com/brianwilson/archive/2007/03/05/part-1-event-handlers-everything-you-need-to-know-about-microsoft-office-sharepoint-portal-server-moss-event-handlers.aspx
• http://www.davehunter.co.uk/Blog/Lists/Posts/Post.aspx?ID=69

One of my clients was using the Content Editor Web Part on one of her page layouts (instead of using a RichHtmlField – long story). She noted that she could not select the “Use Predefined Table Format” in the Table Editor web dialog. Hmmm… I didn’t do anything specific to disable that capability, so I needed to do some digging.

Since I was using a custom publishing site definition, I needed to determine if this behaviour was happening with the default Publishing Portal definition. Sure enough, adding a CEWP to the home page of the Publishing Portal yielded the same effect: I could not use the predefined table formats. I then check the Press Releases default page, which does have a RichHtmlField for me to play with. I can use the predefined formats here. I proceeded to add a CEWP to the zone at the bottom of the page, and here I can also use the predefined formats. Interesting…

I fired up my favourite search engine, and came across this posting from Microsoft: How to enable the “Use Predefined Table Format” setting when you use a Windows SharePoint Services template in SharePoint Server 2007. Cool! But note the location of the CSS: /_LAYOUTS/1033/STYLES/HtmlEditorTableFormats.css. In my case, I have the French language pack installed, which means I have to account for the 1036 LCID also.

I checked the master pages and page layouts that PublishingLayouts feature use, and note that there is not a reference to that CSS. Nor is it in the page layouts found in the PublishingResources feature. What gives? What’s the correct syntax?

No matter. I’ll just add a link to the CSS by building out the path to the right LCID folder, using something like System.Threading.Thread.CurrentThread.CurrentUICulture to get the LCID. After some frustrations (which I won’t get into here), I quickly realized that this would not work in my scenario (Canadian English is not 1033) either.

I looked at the source code for my out-of-the-box publishing portal (the Press Releases page). I noticed that core.css also comes from the LAYOUTS/1033/Styles folder. Some more digging, and I realized that I did not need to specify the full path, like this example taken from BlueBand.master:

<SharePoint:CssRegistration name="<% $SPUrl:~sitecollection/Style Library/~language/Core Styles/controls.css %>" runat="server"/>

but instead I needed simply this:

<SharePoint:CssRegistration name="HtmlEditorTableFormats.css" runat="server" />

and SharePoint takes care of the rest, building out the path to the appropriate Styles as required, like this:  

<link rel="stylesheet" type="text/css" href="/_layouts/1033/styles/Htmleditortableformats.css?rev=guYGdUBUxQit03E2jhSdvA" />

Here is a great post which talks about what’s going on, and what renders HtmlEditorTableFormats links. It explains why I could not find it in any of the master pages or page layouts: the RichHtmlField web control inserts CSS links to HtmlEditorTableFormats.css and HtmlEditorCustomStyles.css OnLoad() . <groan! />

Say we wanted to inherit from “Page”, our content type used to look something this (I’ve split up the lines so it will display properly):

0x010100C568DB52D9D0A14D9B2FDCC96666E9F2007948130EC3DB064584E219954237AF3900
188024C0FF7F45CFB85EBB43980DACF5

Meaning, inherit from “Page” (the red part), include a delimiter (00), and then append a GUID.

If we then wanted to extend this content type, we could do this:

0x010100C568DB52D9D0A14D9B2FDCC96666E9F2007948130EC3DB064584E219954237AF3900
188024C0FF7F45CFB85EBB43980DACF500DFA39D91C06D48BDBC415E7CE80A95CD

And so on… You can imagine how hairy-scary the ContentTypeIDs can get if you wanted your inheritance to go a few levels deep.

As per the article, there is a more efficient way; the second ContentTypeID above could become:

0x010100C568DB52D9D0A14D9B2FDCC96666E9F2007948130EC3DB064584E219954237AF3900
188024C0FF7F45CFB85EBB43980DACF501

Where the tail 01 is the extended content type. Thus, we could have:

0x010100C568DB52D9D0A14D9B2FDCC96666E9F2007948130EC3DB064584E219954237AF3900
188024C0FF7F45CFB85EBB43980DACF501
0x010100C568DB52D9D0A14D9B2FDCC96666E9F2007948130EC3DB064584E219954237AF3900
188024C0FF7F45CFB85EBB43980DACF502
0x010100C568DB52D9D0A14D9B2FDCC96666E9F2007948130EC3DB064584E219954237AF3900
188024C0FF7F45CFB85EBB43980DACF503

etc.

And then to extend from either of these:

0x010100C568DB52D9D0A14D9B2FDCC96666E9F2007948130EC3DB064584E219954237AF3900
188024C0FF7F45CFB85EBB43980DACF50101
0x010100C568DB52D9D0A14D9B2FDCC96666E9F2007948130EC3DB064584E219954237AF3900
188024C0FF7F45CFB85EBB43980DACF50102
0x010100C568DB52D9D0A14D9B2FDCC96666E9F2007948130EC3DB064584E219954237AF3900
188024C0FF7F45CFB85EBB43980DACF50201

etc.

IMO, this makes the ContentTypeIDs much easier to work with (and read), and we run less risk of running into URL length issues within SharePoint.

PS. The GUIDs used in the above examples have been changed to protect the coder. Any resemblance to any existing ContentTypeIDs are purely coincidental.

As per MSDN’s documentation for the Microsoft.SharePoint.WebPartPages class and Andrew’s post on v3 web parts, we should now inherit from System.Web.UI.WebControls.WebParts.WebPart when we are building custom web parts, except in the four scenarios he mentions (repeating here for my own records):

1. Cross page connections
2. Connections between Web Parts that are outside of a Web Part zone
3. Client-side connections (Web Part Page Services Component)
4. A data caching infrastructure that allows caching to the content database

However, I came across a situation recently whereby a very simple custom web part (all it did was render a “Get Adobe Acrobat” link, essentially) threw a SharePoint error to the screen when used in conjunction with Variations. Here’s the steps to replicate:

1. Create your custom web part, inheriting from System.Web.UI.WebControls.WebParts.WebPart. Keep it simple; “Hello World” is fine.
2. Build/deploy, etc. Use it in one of your page layouts. Of course, Variations has to be set up/enabled, but turn off automatic creation of target pages.
3. Once the new page has been created, select either “Update Variations” from the Tools menu.
4. SharePoint will start a long running operation, and then eventually throw an error to the screen.
5. The target variation page is actually created, but this error message is annoying, and probably discomforting to the authors.

It took me a while to figure out what was causing the problem. I finally had a thorough look in the SharePoint logs, and found the message that told me the cause. If you are using SpsDev’s ULS Log Reader, filter by Area:CMS, Category:Publishing, or just look for the message “Unable to cast”. The relevant part of the message is:

Unable to cast object of type '******.Website.SharePoint.WebParts.AdobeLinkWebPart' to type 'Microsoft.SharePoint.WebPartPages.WebPart'

Um, what? Why does it want to do that? So…

1. Re-write the web part to inherit from Microsoft.SharePoint.WebPartPages.WebPart.
2. Create a new DWP file to match.
3. Deploy, etc; re-test.
4. Of course, it works without the error.

Microsoft’s own web parts that inherit from System.Web.UI.WebControls.WebParts.WebPart don’t seem to have the same behaviour. Nevertheless, I believe this to be a bug, but one that you should know about when using custom web parts in conjunction with Variations.

• GlobalNavSiteMapProvider
• CombinedNavSiteMapProvider
• CurrentNavSiteMapProvider
• CurrentNavSiteMapProviderNoEncode

That is, all of these SiteMapProviders use the same base code to generate a data source, but their “output” differs slightly due to the different attributes that are applied.

Recently, we wanted to filter out the pages from showing up in our left-navigation. You can do this at the rendering stage, but since the PortalSiteMapProvder gives us an IncludePages property, we can simply create a new entry in web.config for our “custom” provider, like this:

<add name="CurrentNavNoPagesSiteMapProvider" description="CMS provider for Current navigation" type="Microsoft.SharePoint.Publishing.Navigation.PortalSiteMapProvider, Microsoft.SharePoint.Publishing, Version=12.0.0.0, Culture=neutral, PublicKeyToken=71e9bce111e9429c" NavigationType="Current" EncodeOutput="true" IncludePages="Never" />

By default, there is also a 50 returned-items limit; we can set the DynamicChildLimit to “0″ to override this.

<add name="CurrentNavNoLimitSiteMapProvider" description="CMS provider for Current navigation" type="Microsoft.SharePoint.Publishing.Navigation.PortalSiteMapProvider, Microsoft.SharePoint.Publishing, Version=12.0.0.0, Culture=neutral, PublicKeyToken=71e9bce111e9429c" NavigationType="Current" EncodeOutput="true" DynamicChildLimit="0" />

Of course, you can combine the different properties to come up with a combination you need. The next thing we would need to do is reference these new providers, and voila!

And if you haven’t read Chris Richard’s series of articles about MOSS Navigation and how to get better performance using the PortalSiteMapProvider, you really should…

Oftentimes, we need some code to execute, but only in the “published” state (old MCMS terminology). We might want a component to run certain logic, but it’s really only relevant if the page is in a live/published state. In other words, the logic does not matter when we are viewing the page as authors, editors, or administrators – we either don’t care, or we just don’t want the logic to execute. (Could be vice-versa; execute some code only if we’re NOT in published state.) 

For example, my UE developer asked me to hide all mark-up surrounding a publishing site field. After all, if there isn’t any content to display, then why bother rendering the DIV tags, or possibly some heading (H) tags? By performing a check for content, we can avoid a situation where a “News” header appears, but there’s nothing it. So, I created a control that wraps around all the mark-up that comprises a UI element/section. If there is no content, the control, and its children, will not render. However, we always want it to render in editing mode; otherwise, we can’t add content back in! 

This scenario was fairly simple to solve: write a control that inherits from Microsoft.SharePoint.WebControls.BaseFieldControl, and only run the code to check for content if we are in published mode:

if (this.ControlMode == SPControlMode.Display)
{
    // do something.
} 

This is all fine and well, since BaseFieldControl can be traced back to Microsoft.SharePoint.WebControls.FormComponent, which is the last point in the hierarchy that has the ControlMode property. If you go further up the tree, Microsoft.SharePoint.WebControls.SPControl does not have the ControlMode property… I have no idea why not.

Why is this a problem? Well, my UE developer wanted to check multiple fields. I could not inherit from BaseFieldControl any longer, since it is meant to represent a single field, not multiple fields. So I decided to inherit from SPControl instead. (In the end, I probably could have inherited from System.Web.UI.WebControls.WebControl, but it seemed to make sense to stick within the SharePoint namespace.)

After much searching, including spending a lot of time in Reflector, specifically searching for Microsoft.SharePoint.Publishing.WebControls.PageDisplayMode and Microsoft.SharePoint.Publishing.WebControls.SPControlMode (both enums), I finally came across this *internal* and *sealed* class in the Microsoft.Office.Server.Utilities namespace: PageUtility. But we can’t use it! However, inside PageUtility is a method called IsPageCurrentlyInSomeEditMode() (nice, huh?) and more importantly, a property called FormContextMode, which returns an SPControlMode object… interesting.

Looking closer, I saw a line (similar to) SPContext.Current.FormContext.FormMode (!!). As Sezai pointed out, FormContext is an SPFormContext object, which contains two (potentially) very useful properties: FormMode and FieldControlCollection: 

• FormMode gives us a way to check against the enum SPControlMode to determine what “state” we’re in.
• FieldControlCollection returns an ArrayList of field controls (skipping all the other server controls on the page).

Now, I can do a check like this: 

if (SPContext.Current.FormContext.FormMode == SPControlMode.Display)
{
    // do something.
}

Also, with FieldControlCollection, I can iterate over the list of defined fields for the current page, looking for some specified fields. Nice! SPFormContext is definitely useful, and I’m surprised there hasn’t been any postings about it until Sezai came along (try searching for SPFormContext…).

SPSite Represents a collection of sites on a virtual server, including a top-level site and all its subsites. Each SPSite object, or site collection, is represented within an SPSiteCollection object that consists of the collection of all site collections on the virtual server.

Mmmmm… ooo-kay… what does that mean?

The SPWeb class simply says:

Represents a SharePoint Web site.

Wow. Enlightening. Looking back to my first experiences working with the SharePoint object model in WSS2/SPS2003, I must say this was one of the more confusing points for me. And it’s easy to see why it can be such a confusing/frustrating experience for developers working with the API for the first time. Now that I’ve worked with WSS3/MOSS code more closely, specifically with Publishing Sites where there are many child “sites”, I’ve come to understand the world of SPSite and SPWeb objects.

The problem lies with the difference in terms used between the SharePoint user-interface and the object model. When we are speaking to end-users, they are familiar with the term “creating SharePoint team sites”. However, everytime you create a “site” from the UI, an SPWeb object was created.

It doesn’t help that the MSDN documentation uses the following type of naming conventions in their code samples:

SPSite mySiteCollection = new SPSite("http://servername/");
SPWeb mySite = mySiteCollection.AllWebs["Site_Name"];
SPWeb myRootSite = mySiteCollection.RootWeb;

For me, it would have been much clearer if they wrote something like this instead:

SPSite mySite = new SPSite("http://servername/");
SPWeb myWeb = mySite.AllWebs["Site_Name"];
SPWeb myRootWeb = mySite.RootWeb;

While the description for SPSite may be valid, a typical SharePoint application web site only has one top-level site collection. Therefore, in this url http://servername/site1/site1a/, there are actually three SPWeb objects, and only one SPSite object.

SPSite site1 = new SPSite("http://servername/site1/");
SPSite site1a = new SPSite("http://servername/site1/site1a/");
bool sitesAreEqual = site1.Equals(site1a);  // sitesAreEqual should evaluate to true.

SPWeb web1 = site1.OpenWeb();
SPWeb web1a = site1a.OpenWeb();
SPWeb rootWeb = site1.RootWeb; // or site1a.RootWeb; would return same instance.

See the SPSite.OpenWeb() method for more examples: http://msdn2.microsoft.com/en-us/library/ms474633.aspx.

SPSite itself is not a “collection” in the sense that comes from CollectionBase, for example. In fact, both SPSite and SPWeb inherit directly from System.Object. Therefore, to use a name such as mySiteCollection is confusing/misleading.

The key thing to keep in mind is that as developers, we need to use the technically accurate terms when speaking with each other (even if MSDN doesn’t), and reserve the marketing/UI terms when speaking with people who would never see the object model. (Note: there are examples of these kinds of terminology differences all over the place in SharePoint 2007.)

I hope this clears things up a bit…if you find something that is not correct/accurate, please let me know!

Anyone who’s done some development work with SharePoint probably already knows about this article, but I wanted to place it here for reference:

Best Practices: Using Disposable Windows SharePoint Services Objects

Review the article very carefully… there are things we do often such as getting to an SPSite’s RootWeb, like this:

SPSite site = SPControl.GetContextSite(HttpContext.Current);
SPWeb rootWeb = site.RootWeb;

In this case, it’s pretty obvious (based on the article) that we need to call:

rootWeb.Dispose();

However, if you were to access a property like this:

string rootWebTitle = site.RootWeb.Title;

the article states that you should call

site.RootWeb.Dispose();

which is not obvious, in my opinion. So to keep/ensure your SharePoint site/application runs as smoothly as possible, clean up after yourself! 

EDIT (September 2008):

This is kind of old news by now, but here is another article from Andrew Woodward (which references 3 articles other than MSDN). Worthy to note that we need to properly Close() all PublishingWeb objects as well.
http://www.21apps.com/2008/02/sharepoint-ate-all-my-memory-dealing.html

Roger Lamb’s blog has some really good examples. Also make sure to read the comments.
http://blogs.msdn.com/rogerla/archive/2008/02/12/sharepoint-2007-and-wss-3-0-dispose-patterns-by-example.aspx

Stefan Gossner gives a pretty good in-depth look at how memory is consumed.
http://blogs.technet.com/stefan_gossner/archive/2007/11/26/dealing-with-memory-pressure-problems-in-moss-wss.aspx

Finally, a post about application pool/worker process recycling and SharePoint.
http://blogs.msdn.com/steveshe/archive/2007/12/17/overlapped-recycling-and-sharepoint-why-sharepoint-requires-it.aspx