Chapter 3: The SharePoint User Experience (Part 2 of 2) (Professional SharePoint 2007 Development)
This article is an excerpt from Professional SharePoint 2007 Development, by John Holliday, John Alexander, Jeff Julian, Eli Robillard, Brendon Schwartz, Matt Ranlett, J. Dan Attis, Adam Buenz, and Tom Rizzo (Chapter 3 written by Brendon Schwartz), from Wrox (ISBN 978-0-470-11756-9, copyright Wrox 2007, all rights reserved). No part of these chapters may be reproduced, stored in a retrieval system, or transmitted in any form or by any means—electronic, electrostatic, mechanical, photocopying, recording, or otherwise—without the prior written permission of the publisher, except in the case of brief quotations embodied in critical articles or reviews.
Previous Part: Chapter 3: The SharePoint User Experience (Part 1 of 2) (Professional SharePoint 2007 Development)
Contents
Understanding Content Types
Windows SharePoint Services Pages
Windows SharePoint Services Mobility
Summary
Additional Resources
Understanding Content Types
Microsoft SharePoint Server 2007 gives you the ability to organize and store data through the use of content types. Content types are what make it possible to store different types of content in the same list or document library. Basically, content types are a collection of settings that you can define and apply to your data. In SharePoint 2.0, when a list was created, you would define a set of columns that defined all data contained in that list. Every column was set up to track data for all items on that list, and all of the items had to fit into the schema defined by that list, and were ultimately contained by that location.
In SharePoint 3.0, the items in a list do not have to have metadata that fits into every column defined in the list. Metadata is the columns that have information that describe the information you are storing. For instance, you might store a document in a library, and the metadata would be items such as title, modified, and modified by. You can now take two different items that have different categories of information, and put them in the same list or document library. For example, if you needed to store information about houses that you are selling as a real estate agent, you might store the listing contract and offers. Each set of documents might have a different set of metadata, but they need to be stored together in the same list. This allows you to store data in a more centralized, organized manner. The different content types would each have their own defined columns that would allow them to store different information, but the content types would still coexist in the same list or document library. These different content types can also have different workflows or custom attributes assigned to them, allowing different courses of action to be taken.
Using File Formats for Content Types
Content types allow data to no longer be bound to a single location. This new structure allows content types to be made available across multiple sites. They are no longer defined by a list or document library, as they were in SharePoint 2.0. The content types can now be defined, stored, and managed through the site collection. Additionally, content types are not bound by file format, either. When you create a new document of a certain content type, SharePoint will automatically create the document using the template that has been set up. However, you have the ability to upload a file to the document library, defined as the same content type, and the type of file does not matter. Content types can also be assigned to list items and folders, which have no file format.
Tip
Content types made for lists can only be used for lists, and ones made for document libraries can only be used for document libraries. However, content types made for folders can be used for either.
Look at this example. A real estate agent may have many listings to manage. She also gets offers on those listings—some that are acceptable, and some that are not. The agent may want to store listing documents and offer documents in the same document library, but the columns defined for each are going to be different. In this example, two content types could be defined—call them Listings and Offers. The Listings content type will define columns that are associated with a listing, such as: listing date, listing price, seller name, and seller phone number. However, the Offer content type would have a different set of defined columns, such as: offer date, offer price, closing date. Each of these content types has different metadata, but they can both be stored in a central document library.
You can view the entire list of site content types by following these steps:
Navigate to the site collections main page.
From a publishing page, click Site Actions, then Site Settings, and then Modify Site Settings, or from a standard page select Site Actions, then Site Settings.
Under the Galleries section, select Site content types, which lists all of the content types in the site collection.
Creating Content Types
Many times companies will have their own definition of what describes data. In that case, you will want to create your own content types that can be part of the site collection. To create your own content type, use the following steps:
Click on the Site Settings page
Then under Galleries, click on the link that takes you to Site content types. Here, you will find all of the content types that you can use on the current site and its subsites.
Click on the button available at the top left labeled Create to create a new content type.
Enter a meaningful name and description, then select the parent type of List Content Types and the parent content type Item.
Keep the group as Custom Content Type, and press OK.
The content type of Item is the most basic type of content type. The Item content type only contains a field called Title. When a new content type is being created, the default settings are copied from the parent content type. Also, when the parent content type is changed in the future, the changes can also be pushed down to the child content types. This makes inheriting and changing a content type much easier than having to change every item that has used the content type. Being able to inherit types allows for a much more meaningful use of data and enables you to easily build more complex sets of data.
On the New Site Content Type page, specify the name and description of the new content type. In the example shown in Figure 3-7, the name of the new content type is Offers Made. Next, select a parent content type from the drop-down list, and then select the actual parent content type. Again, remember that a content type created for lists can only be used for lists, and one made for a document library can only be used for a document library, but a content type made for a folder can be used for either. In the example, the parent content type is set to Document Content Types and the Parent Content Type chosen is Document. Next, choose a new or existing group to put the content type into, and then click OK. Because a new content type is being created, Custom Content Types was chosen for the group.
Figure 3-7. New Site Content Type page
.gif "New Site Content Type page")
Assigning Settings to Content Types
Content types have many attributes that need to be set when they are created. When the new content type is created, SharePoint brings up the Site Content Type page for that new content type. It is here that you can assign all of the settings to your new content type. A content type can include information such as properties, workflows, document templates, custom forms, and custom information that is stored in XML.
Under the first heading, Settings, there is a link to change the name, description, and group. Since all of these settings were just set when the content type was created, they are okay for now. The next link is for advanced settings. Because this content type is a document content type, this link allows for the assigning of a document template. Whenever a new document is created using the Offers Made content type, SharePoint automatically uses this assigned document template.
The advanced setting page is also where the content type can be set to read-only. If the content type is not read-only, it can be modified later by users through the user interface in SharePoint. Below the Read Only option is the Update Sites and Lists section that sets inheritance for the updates of the content type to all of the child sites and list content types that inherit from it. Back at the Site Content Type page, the link Workflow settings is used to view or make changes to the workflow settings for the new content type. The link Delete this site content type is used to delete the new site content type.
Windows SharePoint Services Pages
WSS 3.0 has two types of pages, called administrative pages and user pages. Both are ASP.NET 2.0 pages, but they were designed to use different master pages. Every page can contain a master page file using the MasterPageFile attribute of the @Page directive.
Administrative pages—These pages are used to provide management features such as list settings and web pages under Site Settings. This would include the administration pages, as well as the page that uses the
application.masterpage. These pages can be shared across many sites.User pages—These pages are the pages generated by the end user and the basic pages required to display information to the user.
Administrative Pages
Administrative pages provide end users with management ability through the user interface. These pages do not contain dynamic content such as Web Parts, and they use a different master page than the content pages. These pages use the master page ~/_layouts/application.master. These pages are also known as application pages because they inherit their functionality from the administration context.
User Pages
User pages are created by the end user or are used to display information to the user. Each page has the value of ~masterurl/default.master as the default master page, which allows the site designer to make a modification to a single page for the entire site. Keep in mind that this only affects the pages that have the value of ~masterurl/default.master.
Master Pages
Master pages are not a new concept to the programming world. They are a common solution used for ASP.NET 2.0 pages. Prior to master pages, developers used server-side includes, scripts, and user controls to help them provide a consistent look and feel across the entire site. Master pages were designed to allow developers to create a single version of the common elements of a page and then create content areas that each page could define. Master pages are another set of technology that SharePoint gives developers to use and implement due to the fact that it is built upon ASP.NET 2.0 functionality. The master page in SharePoint allows a site creator to define the common look and feel of a site in a single location. It also allows for the end user to modify the master page for designers such as SharePoint Designer 2007.
default.master
The main master page for the content pages is default.master. This page is located on each front-end web server. The default.master page contains many content placeholders to display the correct data from content pages. Any custom master page must contain the same set of the content placeholders or the page may not be rendered correctly. Whenever a new page is created, the default.master page will be added to the @Page directive. See Figure 3-8. Some of the common placeholders are for the navigation bars and main content area.
Each site can use a different master page, but each master page must be defined within a site collection.
Figure 3-8. User master page
.gif "User master page")
To correctly display the Web Parts, the default.master page will contain one WebPartManager control which in SharePoint is the SPWebPartManager and one WebPartZone control that will be contained in the content pages. The WebPartManager class maintains the Web Parts, location, and personalization that a content page contains.
Note
The WebPartManager control must be declared before any of the WebPartZone controls to provide the web part zone elements shown on the page.
What About Ghosting/Unghosting
One major topic with SharePoint 2003 was a concept known as ghosting and unghosting. A page would be known as ghosted if it had not been customized. The problem was that if you modified a page (unghosted), especially with Front Page 2003, the page would be saved into the database, and you would lose the enhanced performance of using the file off of the disk. The other problem was that once you unghosted a page in SharePoint, there was no supported way from the user interface to re-ghost the page back to the original look, and even if you did re-ghost it back, all of the work for that page would be lost.
Some of the problems facing unghosting a page were:
A small performance loss from getting the cached version directly from the physical disk drive. This occurred because there were more trips to the database to get multiple sets of information.
Changes to the site templates did not affect the pages that were unghosted. This could sometimes be a big problem if there were many pages, say for a corporate portal that was customized with FrontPage 2003.
With SharePoint 2007 the problem does not disappear, but does become less of a problem. There are few reasons why this is not as much of a problem, such as:
ASP.NET 2.0 allows providers in many areas of the ASP.NET framework. One such area is the Virtual Path Providers. SharePoint implements a custom Virtual Path Provider that allows pages to be retrieved from the SQL Server database and then sent to the ASP.NET 2.0 page parser.
SharePoint now uses ASP.NET 2.0 to parse and compile the web pages, which provides much needed extensibility and all of the functions of ASP.NET.
Many page designers found it difficult to revert pages back to the original state. Now, with SharePoint Designer 2007, you can simply click on the page to allow you to revert back to the original file.
As you can see, there are really no problems in creating customizations with pages in SharePoint 2007. The content will still be stored in the database, but the ASP.NET team made sure to provide all of the required functionality to SharePoint inside of the ASP.NET architecture. Also, to help users understand the difference between the two scenarios, SharePoint now calls the action of changing the pages "Customized" and "Uncustomized."
Editing SharePoint Master Pages
To edit a master page in Windows SharePoint Services, Microsoft recommends two options. The first option is to make a local copy of the default.master file simply by using the copy-and-paste functionality in Windows Explorer. Or, you can use a tool like SharePoint Designer 2007 to make the changes. If you are making major changes to the master page, I would recommend taking the time to evaluate using SharePoint Designer 2007 with its integration abilities for SharePoint 2007. Even if you make a change in SharePoint Designer 2007, you can still download the master page that you created or save it into a source control system. Office SharePoint Designer 2007 will provide more functionality than just editing a master page, but it is one of the only products on the market today that allows you to edit the master page in a WYSIWYG manner.
Tip
Microsoft recommends that you do not edit the default.master file that is shipped with Windows SharePoint Services. This file can be changed by upgrades or service packs, unless it is edited.
Creating New Content Pages
As discussed earlier, the master page associated with pages is the default.master file. There are situations in which you might want various pages to reference different master pages. With ASP.NET 2.0, you can simply reference a master page with the following @Page directive. Many companies will want to have a different layout than the default master page that is provided with SharePoint. You can easily make your own master page for all of your pages to have the same look and feel across those pages.
<%@ Page MasterPageFile="my.master"%>
The MasterPageFile directive tells ASP.NET 2.0 to look on the local file system for a file called my.master. This works for basic web applications, but SharePoint 2007 needs the ability to make the page use master pages that are designed for the correct site. To accomplish this, Microsoft has created a library just to hold master pages, called the master page gallery. This allows users to create as many master pages as the site requires and upload them locally to the site collection. To navigate to the master page gallery go to the site’s settings page and use the Master pages and page layouts link to show the page in Figure 3-9.
Master Page Locations
In order to easily reference master pages from the content pages, SharePoint 2007 provides tokens that can be used to direct the content page to the right location. There are two types of tokens that you can use when designing the content pages: dynamic tokens and static tokens.
Dynamic tokens—These tokens allow developers to modify variables in code that can change the location of the master page.
Static tokens—These tokens allow you the ability to create a scope of the page and the master page location.
Figure 3-9. Master Page Location
.gif "Master page location")
Tip
These tokens are specific to SharePoint 2007 and are only used within SharePoint 2007. An error will be thrown in applications that only use standard ASP.NET 2.0.
SharePoint provides the following dynamic tokens to use when developing pages.
Table 8. Dynamic tokens
| Token | Location |
|---|---|
|
The entire token must be used and is replaced by the value in MasterURL, set to |
|
The entire token must be used and is replaced by the value in |
The following table describes the static tokens you can use to develop pages in SharePoint.
Table 9. Static tokens
| Token | Location |
|---|---|
|
The master page is located in the site-level master page gallery. The token will be replaced by the site URL location and the master page will remain. |
|
The master page is located in the site collection–level master page gallery. The token will be replaced by the site collection URL location, and the master page will remain. |
Dynamic Tokens
There are only two dynamic tokens that are used within SharePoint. These tokens allow you to define a token name that can be changed without having to change each page that has been created. This can be very useful when trying to build many pages for a site or importing pages from another site that you have already created. When you use the dynamic tokens, the entire token is replaced by the value of either MasterUrl or CustomMasterUrl by SharePoint. When SharePoint is installed, both MasterUrl and CustomMasterUrl point to the same location, which is the local site level master page gallery located at
/_catalogs/masterpage/default.master.
Static Tokens
To allow you to keep the master pages scoped to the local site or site collection, SharePoint provides two static tokens that can be used with master pages. This allows you the ability to select a master page in the site collection master page gallery by using the ~sitecollection/<master page>. To use the local site master page gallery you simply use ~site/<master page>.
Windows SharePoint Services Mobility
With the large adoption of SharePoint in many organizations, the need to be able to view data from many locations has become critical. This is especially true for organizations that have employees on the move such as a sales force or mobile workers. The big question becomes how to keep your employees connected to the data in SharePoint. One solution is to simply provide the lists using mobile views. I have already talked about what a view is, but now you will look at how to add mobile views as well as develop your own view for the mobile pages.
Defining a List as a Mobile List
To define a list as a mobile list, set the mobile options of the list settings through the user interface or configure the list through XML. To set the list as a mobile list through the user interface, first navigate to the site and list that you want to display as a mobile list, then navigate to the lists’ settings page. There are two major settings that can be used to provide a page with mobile settings. These settings are part of the list XML definition file. When the list is configured through the user interface, the URL for the mobile view of the home page, as well as a direct link to the mobile list, is located below the options for setting a list to a mobile list.
MobileView attribute—If this attribute is set to true, the list will appear in the mobile pages as a valid mobile list.
MobileDefaultView attribute—When a list is a valid mobile list, setting this value to true will make the list the default list that appears to the user. You can only have one default mobile view per list.
Note
A mobile list is just a standard SharePoint list that is marked with mobile attributes. The mobile list will still show up in the selection of lists on all device types, including a regular browser.
Mobile Pages
To view a list as a mobile list, start by providing the list with a mobile view and then navigate to a site that has a mobile list. Navigating to a mobile page has been simplified by having Windows SharePoint Services perform a redirect to the mobile page. To view a site in a mobile-rendered format, Microsoft has provided the ability to simply place /m at the end of the site’s URL location, as follows:
http://<server name>/<site path>/m
Open either your mobile browser or Internet Explorer, and navigate to https://localhost/m.
Tip
You can view the mobile pages in a regular browser such as Internet Explorer to make sure that the pages are working, before trying them on a mobile device. This can help when trying to resolve some issues and determine if the problem is with the Windows SharePoint Server or with the mobile device itself.
The built-in mobile pages are located at C:\Program Files\Common Files\Microsoft Shared\web server extensions\12\TEMPLATE\LAYOUTS\MOBILE. In addition to the list of pages, there is also a web.config file that has mobile-specific settings for the site. These settings are shown in the following tables.
The following table lists the common mobile pages used on a standard site.
Table 10. Common mobile pages used on a standard site
| Page Name | Description |
|---|---|
|
The default page used for redirecting the mobile pages to the correct site home page |
|
The mobile page used to display all errors to the user |
|
The login page for handheld mobile devices |
|
The logout page used to complete a session |
The following table lists the mobile pages that are commonly used on the team site.
Table 11. Common mobile pages used on a team site
| Page Name | Description |
|---|---|
|
Displays a single item from the list item with the valid mobile fields that can be displayed |
|
Provides the ability to edit a single item selected from the list of items |
|
The default page for team sites used to make the mobile available lists viewable |
|
Creates a new list item from the mobile device using the mobile template fields |
|
Used to display the list of items for the document library of lists selected with a mobile view |
The following table lists the mobile pages that are used in the blog sites.
Table 12. Mobile pages that are used in the blog sites
| Page Name | Description |
|---|---|
|
The default page for blog sites used to make the blogs mobile available |
|
Deletes the current blog post with a confirmation about the deletion that will send the item to the Recycle Bin |
|
Displays all of the lists available on the blog site |
|
Creates a new comment for the blog post with the required mobile fields |
|
Provides the ability to enter a new blog post from a mobile device using the standard ASP.NET mobile controls to enter data |
|
Allows the mobile device the ability to show the comments from the blog post |
Mobile web.config Settings
The web.config file contains many settings that are specific to mobile pages and can be modified by editing the file or through code. If you have more than one front-end web server, each server will contain its own copy of web.config file, so you’ll have to propagate any changes to all servers.
Page Redirection
To allow the user to navigate to the right page, Microsoft uses something called the bi-level redirection feature. This feature lets all users navigate to the same page, which is the entry point, and then be redirected to the correct default page of the site. When you navigate to a standard mobile page, you will be redirected to the correct mobile list for that page. There are two standard default views for mobile pages:
mblists.aspx—This is the default mobile page layout for the Team Site Mobile pages. This page only displays the lists that have enabled a mobile view.
http://<servername>/<site path>/_layouts/mobile/mbllists.aspxbloghome.aspx—This is the default mobile page layout for the Blog Site Mobile pages. The view type determines which set of blogs are displayed. If ViewType is set to 2, then the blogs of the current user will be displayed; otherwise, all blogs will be displayed.
http://<servername>/<sitepath>/Blog/_layouts/mobile/bloghome.aspx?ViewType=Integer
Tip
Microsoft recommends not modifying the default pages that are shipped with Windows SharePoint Services because your changes could be overridden by an upgrade or a patch. Be sure to make a copy of the default page and create your own page based on that copy instead of changing the default file.
Displaying the Default Pages
Every list can contain a mobile page. When you set up the mobile list, you can have multiple views of the data but only one default view. The default view is the one selected first on the mobile drop-down list control (see Figure 3-10).
Figure 3-10. Mobile drop-down list control
.gif "Mobile drop-down list control")
Displaying Columns on the Mobile Page
The browser can display very complex types of columns in a full browser, but the mobile device has some limitations on what it can display. The bandwidth and screen size of the mobile device being used can have an impact on what is displayed. At times, you have to develop pages that can be displayed on a variety of different devices, all with different views. The following table lists the columns that display on a mobile device, and the ones that can be edited by using the mobile pages.
Table 13. Columns that display on a mobile device
| SharePoint Field Type | Control in Read-only Mode | Control in Edit Mode |
|---|---|---|
Single line of text |
|
|
Multiple lines of text |
|
|
Choice (menu to chose from) |
|
|
Number (1,1.0,100) |
|
|
Currency ($, ¥, €) |
|
|
Date and Time |
|
|
Lookup (information already on this site) |
|
|
Yes/No (check box) |
|
|
Hyperlink or Picture |
|
|
Calculated |
|
|
Mobile User Control Templates
To extend pages, you need to create control templates that Windows SharePoint Services can consume. These templates are made up of basic ASP.NET control files and are stored in files with the extension of .ascx. Microsoft stores all of the default templates in the control template folder in a file named MobileDefaultTemplates.ascx. In order for SharePoint to find and load the file, it must be stored in a location where SharePoint knows to look for it. That location is under the SharePoint directory.
Defining Browsers
To allow for multiple types of browsers, ASP.NET provides a configuration file where new mobile browsers can be defined. This is very useful with the number of mobile devices that are released each year. And, as the wireless industry adds more capability to connect through phones, this number is bound to increase even more. To add your own browser, look in the ASP.NET 2.0 folder App_Browser on your local front-end web servers. Inside of that folder is a file called compat.browser. Defining a new mobile browser is outside the scope of this book, but look at the ASP.NET 2.0 documentation on the browser element for more information at https://msdn.microsoft.com/en-us/library/ms228122.aspx.
State Management of Mobile Pages
Most mobile browsers do not have the ability to store state in cookies like full-fledged browsers do. You might have already noticed that when you select a page, any data that must be sent back to the server is stored in the Address bar of the browser.
Displaying on a Small Device
Due to the screen limitations of mobile devices, all of the lists and all of the text may not fit onto the device. When this situation occurs, Windows SharePoint Server uses a preconfigured length to determine where to stop displaying the text that is too wide for the device. Instead of just cutting the text off at that point, SharePoint adds three dots called an ellipsis to notify the user that there is more information that could not be displayed on that screen. The default settings are stored in the mobile web.config file in the application settings. If the key is set to zero or if the key does not in appear in the web.config file, the ellipsis will not be displayed. Any changes to the values made in code will overwrite the default values from the web.config file.
Working with Large Lists
When the page has too many items to display on a single mobile page, the page displays only a set number of list items. It then allows the user to navigate to other pages. This navigation on the mobile device is known as pagination, and there are a number of pages that already provide this functionality. These pages are the home pages and the viewing pages. To provide this pagination functionality, SharePoint relies on the underlying ASP.NET 2.0 framework and the ASP.NET 2.0 mobile controls for pagination.
Creating Custom Mobile Pages
When developing custom mobile pages, you use a new set of mobile controls in the Microsoft.SharePoint.MobileControls namespace. Keep in mind that all of SharePoint is built on Microsoft ASP.NET 2.0 and that the mobile controls in Windows SharePoint Services are built on top of the ASP.NET 2.0 mobile controls.
Tip
It is easy to use mobile pages, but it can be difficult to update mobile pages for an entire portal and not just a single site.
Creating Mobile Pages
When designing mobile pages for SharePoint, you can use a template that contains the mobile controls on the page. To define a template, create a SharePoint mobile page that is made up of a header, content, and footer section. First create a template, and then place it in the directory where SharePoint loads all of the mobile templates.
Open the following folder:
\Program Files\Common Files\Microsoft Shared\web server extensions\12\TEMPLATE\CONTROLTEMPLATES.Create a new file named
CustomMobileTemplates.ascx.Add the following imports and directives:
<%@ Control Language="C#" %> <%@ Assembly Name="Microsoft.SharePoint, Version=12.0.0.0, Culture=neutral, PublicKeyToken=71e9bce111e9429c" %> <%@ Register TagPrefix="mobile" Namespace="System.Web.UI.MobileControls" Assembly="System.Web.Mobile, Version=1.0.3300.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a" %> <%@ Register TagPrefix="SharePoint" Namespace="Microsoft.SharePoint.WebControls" Assembly="Microsoft.SharePoint, Version=12.0.0.0, Culture=neutral, PublicKeyToken=71e9bce111e9429c" %> <%@ Register TagPrefix="SPMobile" Namespace="Microsoft.SharePoint.MobileControls" Assembly="Microsoft.SharePoint, Version=12.0.0.0, Culture=neutral, PublicKeyToken=71e9bce111e9429c" %> <%@ Import Namespace="Microsoft.SharePoint" %>You can add either the header, contents, or footer template in the custom control. This code adds one of each:
<SharePoint:RenderingTemplate RunAt="Server" ID="Mobile_STS_HomePage_Title"> <Template> <mobile:Label RunAt="Server" Text="Team Site Custom Mobile" Font-Size="Large" Font-Bold="True" /> </Template> </SharePoint:RenderingTemplate> <SharePoint:RenderingTemplate RunAt="Server" ID="Mobile_STS_HomePage_Contents"> <Template> <mobile:Label RunAt="Server" Text="Custom Mobile Control" /> <mobile:Label RunAt="Server" Text="" BreakAfter="true" /> <SPMobile:SPMobileListIterator RunAt="Server"> <SPMobile:SPMobileList RunAt="Server" BaseType="DocumentLibrary"/> </SPMobile:SPMobileListIterator> </Template> </SharePoint:RenderingTemplate> <SharePoint:RenderingTemplate RunAt="Server" ID="Mobile_STS_HomePage_Navigation"> <Template> <mobile:Link RunAt="Server" Text="Wrox" href="http://www.wrox.com/" /> <SPMobile:SPMobileComponent RunAt="Server" TemplateName= "Mobile_Default_HomePage_Navigation" /> </Template> </SharePoint:RenderingTemplate>Save the file and the new changes.
Click the Start button, then select Run and type IISRESET.
Navigate to the home page to see the changes.
The following list covers the available templates:
Header Template—The header part of the template can be used in a section to display information that will not change based on the information in the list. This could include such items as a company name, list title, or even the date the list was requested.
Contents—The contents area is usually where the list items are located. Depending on the screen, this could be a list of items, some input areas for data, or even just useful information about an item. To display the contents, use the
SPMobilePageContentscontrol.Footer Template—The footer can contain the actions that need to be performed on the items. There is no reason that these actions could not also be in the header if the list of items were too long on such a small device. The way an action is usually rendered in the mobile device is through a URL.
Summary
This chapter introduced you to the out-of-the-box features SharePoint provides. You looked at how to use these features to "develop" a site from within the user interface as well as how to add to code like CAML to the other user interface elements.
You learned to create web applications and modify them according to the needs of your organization by:
Creating the standard web applications and site collections
Storing data on the server with SharePoint predefined lists and libraries
Modifying the look of the site by adding user interface elements
Creating new content types to store data
Implementing your own set of mobile controls or using the predefined ones
As you can see, there are many changes that you make to SharePoint using the existing framework. Some of these options only require you to add code to the user interface elements without updating or using compiled code.
Now you should be ready to open up your development environment and create the components that make up SharePoint, such as Web Parts. In the following chapters, you will see how all of the elements that you have seen through the user interface can also be created, added, and removed through code.
Additional Resources
Professional SharePoint 2007 Development: Chapter 3: The SharePoint User Experience (Part 1 of 2) (Professional SharePoint 2007 Development)
Professional SharePoint 2007 Development: Book Chapter Landing Page: Chapter 8: Building Personalized Solutions