Get Past the Gaps in SharePoint

Microsoft Office SharePoint Portal Server 2003 and Windows SharePoint Services 2.0 are rapidly growing in popularity. What does that mean to you as an IT pro? It probably means that one or both of these tools are going to be foisted upon you to manage and extend—if they haven't already.

You can find articles and books to help you understand and manage SharePoint Portal Server and Microsoft Windows Share-Point Services (which we'll refer to collectively as SharePoint for the remainder of this article). You can also find resources that explain how to take advantage of Share-Point's many strengths, but few writers familiarize you with SharePoint's weaknesses. During our work with SharePoint, we've spent more time than we like to admit finding the gaps in SharePoint's capabilities and analyzing the potential solutions. This isn't an exercise in product bashing; we simply hope that understanding how to work around a few of the more-obvious limitations—in radical customization, internationalization or localization at the portal level, and Search scope—will make your SharePoint experience even better, right from the get-go.

Microsoft has listened carefully to its customers through means of the various programs that the company sponsors, including the Developer Advisory Council (DAC), the Partner Advisory Council (PAC), and the Technology Adoption Program (TAP). As a result of these initiatives, the next version of Microsoft Office, code-named Office 12, will address many of the gaps we identify. We're actively working with the Office 12 Beta 1 version of SharePoint, but we can't say much about these improvements until the product matures. And you'll still need to know about these gaps if you're using versions earlier than Office 12.

Gap 1: You Need to Brand Your Portal
Many companies need to brand their portals. Many portal products today rely on XML technologies to produce architectures that are easy to customize and extend. SharePoint relies heavily on XML, but Microsoft hasn't made a significant effort to separate the product's business logic and underlying data from the presentation layer—making SharePoint particularly difficult to radically customize. (By radical customization, we mean such things as changing the global navigation structure, modifying the search result template, or building new SharePoint site definitions.) Many other portal vendors (e.g., BEA Systems, IBM, Oracle, Vignette) use their products' ease of customization to position the products against SharePoint. (These other products' architectures completely decouple the presentation from the portal components and site structure; SharePoint has a much tighter coupling of presentation, content, and structure.) Microsoft has a few documents to assist with any efforts to brand SharePoint, but no one guiding document exists.

Solve it. Successfully customizing Share-Point requires careful research. You must understand site definitions—complex sets of ASP.NET (.aspx) and XML files written in Collaborative Application Markup Language. CAML is an XML-based language that developers use to create and customize SharePoint areas, sites, and other elements (e.g., lists). Using a tool such as Visual Studio.NET (VS.NET) 2005 or VS.NET 2003 will facilitate the customization. In addition, you'll find a strong working knowledge of ASP.NET programming and of SharePoint object models helpful.

Be aware that some sources suggest using Microsoft FrontPage 2003 to customize SharePoint. Although using Front-Page is indeed the easiest way to customize a SharePoint Portal Server area or Windows SharePoint Services site pages, doing so causes SharePoint to unghost the page from its underlying template. Simply opening a SharePoint page from within FrontPage and clicking Save—even without making any changes to the page—unghosts the page.

Unghosting is the decoupling of a site or area page from the file-system template from which the site or page was derived. When a site or page is unghosted, Share-Point renders the page content and metadata from the database rather than from its originating file-system template. Any subsequent changes that you make to the file-system template won't be reflected on the unghosted page. Because of template caching, rendering pages from the file-system is likely to be faster than rendering them from the database.

Thankfully, Bluedog Limited provides a Web Part, called GhostHunter, that you can use to detect and reghost an unghosted page. GhostHunter reconnects the page to the file-system template from which the page was derived. Figure 1 shows how the GhostHunter Web Part appears on a page that's being evaluated for its ghosted state. One thing to note about GhostHunter: Any changes you make to an unghosted page are lost when you reghost the page.

Therefore, although Microsoft recommends FrontPage 2003 as the tool for customizing SharePoint, we recommend that you avoid doing so. For small team sites that require minor customization, go ahead and use FrontPage 2003, but for major customizations across many sites, use a tool such as VS.NET.