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.