Page Anatomy
No this post is not about a popular TV show! We'll cover the integrated framework we are using in the next release of SPS + CMS (breaking news - now officially Office SharePoint Server 2007 - I will cover that in a second post later today) to enable people to create, manage and publish the spectrum of very simple to very sophisticated internet sites. We've learned a lot from a variety of customer feedback on ASP.NET, WSS, SPS, CMS, FrontPage and more and hopefully brought this all together in a powerful way. Let's go through them piece by piece.
1) Master Page
Master Pages are an ASP.NET 2.0 feature that lets child pages inherit and re-use a common design. This only makes development and maintenance of the site much easier. New pages don't have to re-do the work of the master. When you want to apply a new design, just change the master. Typically they will contain the branding, navigation, header and footer for the site. We used this to implement the overall "visual blueprint" of SharePoint including access to the end user features. In a more static internet site, little of this will be exposed which is why we'll provide different example master pages to support different scenarios. At rendering time, the page brings in the code from the master so it is always up to date. Master Pages have first class support in the next release of Windows SharePoint Services and Office SharePoint Designer 2007 (also new - wait until next post). In the picture above, the branding section and navigation are part of the master page. I should note that we'll have a lot richer navigation options out-of-box than SPS 2003 or CMS 2002 and if you don't like ours you can buy or build a 3rd-party controls written to the new ASP.NET 2.0 navigation provider interface and still use all our underlying site management capabilities.
2) Page Layouts
Page Layouts are a feature we evolved from CMS 2002 into the new integrated SPS \ CMS (oops Office SharePoint Server - still getting used to that) building on the Master Page support in the next release of WSS. In a large site, there a number of different page types (e.g. Product Description, Press Release, Executive Biography) that should have a standard look and feel. Web site owners not only want to save the work of redoing these, they also want to enforce consistency in the site across the authors and have the flexibility to change them later. The layout is separate from the underlying content in the site. The "page layout" is an ASP.NET page with special "field controls" (aka placeholders in CMS 2002) that know how to bind to WSS data. These layouts may or may not also have web part zones which tells the framework if users can add parts in the browser. More on this below. In the example above, we have a standard Adventure Works "News" Page Template with the authoring console visibile (it isn't by default and people who don't have the rights to see this won't). The stuff on the left is based on field controls and the stuff on the right is in a web part zone we have allowed the page editors to customize.
3) Page
Just like CMS 2002, we use the powerful concept of separating presentation from data in web publishing. In the Office SharePoint Server, the actual "page" is a item a WSS list and the framework knows how to assemble these. This list has columns that are bound to three field controls (title, picture, article). Re-using SharePoint lists for data storage lets us build on existing and new WSS list features like content types, check-in/out, versioning, per item security, workflow and more more. In edit mode, the field controls place constraints on the author for what content they can put in the "page".The screenshot above shows the page with the console visible where authors, approvers, etc. have the appropriate actions based on their role.
4) Web Parts Zones
One of the trickiest aspects of the design was getting the relationship between field controls and web parts right. Field controls are bound to a WSS item so workflow, etc. just works. By design, Web Parts are less tightly coupled. In fact one of their advantage is just using the browser, users can add them to the page. As with WSS and SPS V2, there's a lot of flexibility in this model for customization, personalization and targeting that site owners can choose to use.
a) Customization allows parts to be added for all users - we see a lot of site owners restricting it to a few people for more productive site design in just the browser. It will be fun to see what stuff people do upfront using Page Layouts vs. just-in-time via Web Parts. Feel free to choose any point on the spectrum on using field controls exclusively to using web parts or a combination.
b) Personalization allows each user to set their own parts in the zone - ASP.NET and WSS do the bookkeeping in SQL tables for this. There's a lot of pages where enabling personalization makes sense but many where it does not and you can turn it off.
c) Targeting is an SPS V2 feature (one many CMS 2002 customers asked for as well - it comes return in the trade for page layouts) that lets publishers show different content to developers vs. marketing based on their "audience". In the example above, the top right web part could be targeted just to sales people but everyone else accessing the page wouldn't see the part. We have made targeting even easier in the next release by letting you directly target to an existing group vs. requiring the work (and the privleges) to set up an audience that maps to the group.
5) General Purpose Web Parts
Almost home! One thing we noticed across CMS and SharePoint was many people were writing the same code over and over for many pages and sites particularly for summary "landing pages" and views on business data. While I love our flexibility with ASP.NET, I really want to reduce the code required to build and maintain cool sites. We have also learned the robustness of the ASP.NET and WSS security model can be a double-edged sword. To install a new web part in SharePoint, you need pretty advanced priveleges which many IT admins have restricted in consolidated intranet SharePoint farms and internet prescences for obvious reasons. Often they don't have the time or resources to test new potential web parts. So what we've tried to do is create some extremely flexible, data-driven parts that empower the site publishers.
a) Summary Links and Content-By-Query - These parts address the incredibly common practice of tweaking HTML tables with a list of links and formatting of associated pictures and text. We will be provided a lot of different styles out of the box and support adding your own CSSs. The middle web part in the right column is an example of this. We'll have two versions - one that does versioning and workflow of the links as part of the page and a second (Content-By-Query) that lets you query content elsewhere in the site. We'll probably tweak these names before we ship. But hopefully, a lot less table tweaking to build cooler lists of links, images and people.
b) Business Data Web Parts - We are greatly enhancing the WYSWIG XSLT web part that came with V2 called Data View and let you do rich formatting of remote XML or database calls. You can use this directly against your remote source but it will also be the rendering foundaiton for re-usable business data conncetions we are calling the Business Data Catalog. You can use the BDC to register entities and actions from remote LOB systems like SAP, Siebel and Dynamics as well as databases vs. hard coding them into every web part. Just like with content - we are trying to provide separation of presentation from data and easier re-use and customization. In addition to the BDC parts, we'll have parts designed for simple business intelligence scenarios. In the example above, I've shown a KPI (Key Performance Indicator) Web Part that can bring in data from SQL Analysis Services, Excel Services, SharePoint lists or even just static data.
We're eager to see all the cool intranet, extranet and internet presences you build with the next release!
-- Jeff
