Office SharePoint Server 2007 provides a great amount of built-in functionality. Part of the work of migrating an application from MCMS is determining which functionality can now be provided by using some of the built-in features.
To identify which code to migrate, you must inventory your application code. You can do this by using the CMS Assessment Tool. Run the CMS Assessment Tool on the WoodGroveNet sample application.
This provides a set of different reports that we use to identify code that must be migrated. The tool generates the reports we discuss in this section. You need to determine what these controls are used for and how you go about achieving that functionality in Office SharePoint Server 2007.
First, look at the Site Summary Report from the CMS Assessment Tool. You can quickly see that Woodgrove has 12 .aspx pages and 6 .ascx controls.
Figure 10. Site Summary report for Woodgrove
.gif)
Let’s focus on the .aspx pages first. We will look at the Template Information Summary, which lists the site templates. This helps us determine which .aspx files were template files and which were not. Also, look at the postings count for these templates. It might not make sense to migrate templates with zero or very few postings, because if the old site does not have many postings with these templates, they might not be very important or used.
Woodgrove has only 8 templates and all have postings. Woodgrove is just a sample site with a few templates. In a real application with many templates, you might find that having templates with only 3 or 4 postings would not justify migrating them to Office SharePoint Server 2007. Woodgrove has a total of 12 .aspx pages. The remaining .aspx files (FrameFooter.aspx, FrameHeader.aspx, FrameNavigation.aspx, and Frameset.aspx) are not template files, and we must still determine why they were used and if they are needed in Office SharePoint Server.
Figure 11. Image of Template Information report for Woodgrove site
.gif)
Use the ASP.NET Control Usage report to determine the controls that are present in your application. Following are the controls present in Woodgrove:
Figure 12. ASP.NET Control Usage report for Woodgrove
.gif)
We need to determine what these controls are used for. The ASP.NET Control Usage report, for example, helps you determine which user controls are possible parts of a common look and feel, by determining which controls are present in most templates.
Prior to MCMS 2002 SP2, sites were developed with ASP.NET 1.x, so they were not able to take advantage of concepts such as master pages or new controls such as ASP Login Controls available in ASP.NET 2.0. User (.ascx) controls were usually created to provide elements that could be reused in your templates to give them a common “look and feel."
In general, your controls will be a type that is of one of the following categories:
Navigation and Look and Feel Controls
To determine the look and feel of your application, and the navigation controls that are used, look at the Posting Information report. This report lists the Channel where the postings are. Use the Channel location to build the actual URL of some of the postings. For example for postings “August 30 2001," “Line of Credit," and “Help Desk Analyst," the URLs will look like http://localhost/WoodGroveNet/About+Us/Press+Releases/August+20+2001.htm, http://localhost/WoodGroveNet/About+Us/Help+Desk+Analyst.htm, and http://localhost/WoodGroveNet/Small+Business/Services/Line+of+credit.htm, respectively. Just replace the /Channels part of the Channel information with the address of your server, and replace spaces with a "+" to build the MCMS URL for the posting.
Figure 13. Posting information report for Woodgrove sample site
.gif)
Open your browser, and point to http://localhost/WoodGroveNet/About+Us/Press+Releases/August+20+2001.htm.
Figure 14. Posting for August 30, 2001, using Press Release template
.gif)
You’ll see that the page seems to have a header, a footer, and a navigational element on the left. Next, open Visual Studio 2005, and open the solution for Woodgrove (the default installation path is c:\Program Files\Microsoft Content Management Server\Sample Data\WoodgroveNet\). Look at the template file for this posting (Press Release.aspx) in Visual Studio, and look at the controls that are used to build the chrome of the page.
Now open http://localhost/WoodGroveNet/About+Us/Help+Desk+Analyst.htm in your browser. You’ll see that this page has a similar look and feel. Also open it in Visual Studio, and look at the template file for this posting (Job Posting.aspx). You’ll see that it uses the same controls.
Figure 15. Posting for Help Desk Analyst using the Job Posting Template
.gif)
Finally, open http://localhost/WoodGroveNet/Small+Business/Services/Line+of+credit.htm in your browser, and open the corresponding template file (Services.aspx) in Visual Studio. You’ll see the resemblance.
Figure 16. Posting for Line of Credit using the Services template
.gif)
ASP.NET 1.x did not provide built-in support for site navigation. MCMS Web developers had to create controls that used the Publishing API to provide links that allowed the user to browse the sites more easily.
ASP.NET 2.0 provides a concept of SiteMapProviders, which you can use to determine the ways in which you want your site to be navigated. This provider model allows the separation of the navigation UI code from the data access code. Navigation UI controls that feed on that information and build menus, navigation bars, or breadcrumbs are now available by default.
Using this knowledge, we will replace all navigational controls in Woodgrove with SharePoint Server or ASP.NET 2.0 navigational controls, and replace common look and feel controls by using a master page.
Header.ascx
Header.ascx provides a common header for all pages. This control is present in all templates and implements a header navigation bar. The header navigation bar consists of three links on the green bar at the top of the Web page, as shown in Figure 17.
Figure 17. Header navigation bar
.gif)
The Woodgrove Header.ascx user control encapsulates JavaScript scripts, the McmsDHTMLGlobalNavigation server control, and the graphics elements that make up the header navigation bar.
If you look at the User Methods Calling Publishing API report from the CMS Assessment Tool, you can see that this control uses the Publishing API to create links to Channels.
Figure 18. Methods in Woodgrove code that invoke PAPI functions
.gif)
The report indicates that this control uses several methods of the CmsHttpContext, Channel, and ChannelCollection objects, which indicate that this control is iterating through the Channel hierarchy of the application.
If you look at the Site Manager or the Channel Information report and examine the Channel hierarchy, you can see that the three links it shows are the top-level Channels. The drop-down menus that appear when you pause over a top-level Channel are the sub-Channels.
Figure 19. Channel Information report
.gif)
To provide the same common header in our page layouts in Office SharePoint Server 2007, we can take advantage of the master page concept of the .NET 2.0, and put the HTML elements of the Header.ascx elements directly on a master page.
To provide a menu, ASP.NET 2.0 has a Menu control that can be configured easily to provide a global navigation menu, such as the one provided by the McmsDHTMLGlobalNavigation object. There are third-party .NET 2.0 controls available as well from vendors such as ComponentArt, but we will use the built-in .NET 2.0 controls in this example.
For more information on the ASP.NET 2.0 Menu control, see Introducing the ASP.NET 2.0 TreeView and Menu Controls or ASP.NET Menu Control Overview.
Footer.ascx
The Footer.ascx control creates a common page footer for all pages to provide the copyright message and a legal disclaimer link.
Figure 20. Display of the Footer.ascx control
.gif)
We will put the contents of Footer.ascx directly on our master page.
LeftNavigation.ascx
LeftNavigation.ascx presents a hierarchical tree view of the site along the left edge of the page. This control encapsulates the McmsNavigationControl server control. Look at the User Methods Calling PAPI report to see how this control uses the Publishing API to access the CmsHttpContext, Postings, and Channels from user methods such as FindStartChannel, CreateTree, and CreatePostings. This lets us suppose that it just transverses the Channel and postings hierarchy and creates and populates a TreeControl with that information.
Figure 21. McmsNavigationControl server control
.gif)
This kind of functionality is provided in the built-in master pages, and it is provided using a SharePoint:AspMenu control. For most sites you need to customize only this control. You could also use an ASP.NET 2.0 Tree or Menu control. Office SharePoint Server even provides a PortalSiteMapDataSource data source, which knows how to retrieve data from a PortalSiteMapProvider object and expose this data according to the ASP.NET hierarchical data source interface.
McmsBreadcrumbControl
By looking at the Channel hierarchy in the Site Manager we can determine that this control is providing a trail you can follow to your current position in the repository structure.
The Users Methods Calling PAPI report shows that it uses the Publishing API, and it seems that it builds an array of the parents of the current page and then renders it as a series of links.
Figure 22. Analyzing PAPI usage in the McmsBreadCrumbControl
.gif)
Figure 23. The Breadcrumb control
.gif)
This is a very common functionality, and is now provided in ASP.NET 2.0 with the SiteMap control.