ONET.XML: Defining the Site Definition
| Our site definition folder, MyFirstSiteDefinition, contains several resources that can be strung together to form various site definition templates. ONET.XML's main function is to glue these and other resources together to define one or more site definition templates. In our example, it exists on the physical file system in the C:\Program Files\Common Files\Microsoft Shared\web server extensions\60\TEMPLATE\1033\MyFirstSiteDefinition\XML folder (see Figure 2.4). Figure 2.4. Site definition XML Explorer view. As shown in Listing 2.3, ONET.XML is composed of one Project element, which in turn is composed of NavBars, ListTemplates, DocumentTemplates, BaseTypes, Configurations, and Modules elements. Each element has an extensive sub-element structure, which we detail in the following sections. Listing 2.3. ONET.XML Structure
<Project>: Defining Settings That Apply throughout the Site Definition TemplateThe Project element exists at the top level and is used to define properties that are universal to the site. The allowable attributes are described in Table 2.4. The most popular attributes include AlternateCSS, AlternateHeader, and CustomJSUrl.
AlternateCSS: Using a Custom CSSAlternateCSS is used to override the default SharePoint styles located in C:\Program Files\Common Files\Microsoft Shared\web server extensions\60\TEMPLATE\LAYOUTS\1033\STYLES. It provides a quick and simple way to affect these styles throughout all pages in the site. However, it must reside in the C:\Program Files\Common Files\Microsoft Shared\web server extensions\60\TEMPLATE\LAYOUTS\1033\STYLES folder. Overriding various cascading style sheet styles is more powerful than it might first appear because almost every HTML element within Share-Point has a style associated with it. These style-specified elements include text, toolbars, icons, watermarks, tabs, and many other things. The CSS primarily facilitates changing the formatting or image associated with these elements. AlternateHeader: Creating Your Own Header across All Site Definition PagesThe AlternateHeader attribute allows the substitution of the standard SharePoint headerthe top navigation menu bar. This alternate header is typically an ASPX page and must be located in the C:\Microsoft Shared\web server extensions\60\TEMPLATE\LAYOUTS\1033 folder. Fortunately, all the site's administration pages have ASP.NET code built in to render the custom header if it has been specified. By site administration pages, I mean all the pages that are mapped to the _layouts (C:\Microsoft Shared\web server extensions\60\TEMPLATE\LAYOUTS) virtual directory for the IIS web site. These include the list creation pages, site settings, site administration, and other administration pages. The snippet in Listing 2.4 is taken from the CREATE.ASPX page and is representative of all the alternate header code written by Microsoft. By retrieving the context of the web site and then retrieving the AlternateHeader property, it can determine whether an AlternateHeader was specified through the <Project> element. If an alternate header was specified, it will be executed instead of painting the standard header. Listing 2.4. Alternate Header Snippet Taken from CREATE.ASPX
Unfortunately, this code is not included in any of the Microsoft-provided site definitions. As such, AlternateHeader is designed primarily to customize only the header of administration pages, and not content pages. If you are going to pattern your site definition after Microsoft's site definition templates, you will need to modify every page you want to expose. Considering that there are about 100 pages in the STS site definition folder, it would require a non-trivial amount of time to modify each pageeven if you were only pasting code from the clipboard and saving. More unfortunately, almost every ASPX page within the Microsoft-provided site definition templates has a different HTML structure. Thus, you cannot simply replace the top few lines of an ASPX page with your new and improved alternate header code and move on. You must tediously work this code into each page of your site definition. For the moment, let's ignore the fact that the site definitions do not have the alternate header code embedded within them. Instead, let's go through the much simpler exercise of setting up an alternate header for the SharePoint administrative pages. The first step is to add the AlternateHeader attribute to the Project element within ONET.XML. That change is shown in Listing 2.5. Listing 2.5. ONET.XML Project Element Referencing an Alternate Header
The second step is to create an alternate header page that is located in the C:\Microsoft Shared\web server extensions\60\TEMPLATE\LAYOUTS\1033 folder. The name of the file should match the previously mentioned Project element's AlternateHeader attribute. That code is detailed in Listing 2.6. Listing 2.6. MyFirstSiteDefinition_Header.ASPX Alternate Header Definition
To support the alternate header we just authored, we need to copy the InformationHubLogo.png image file to the C:\Program Files\Common Files\Microsoft Shared\web server extensions\60\TEMPLATE\IMAGES folder. After executing an IISReset and creating a new site with the modified site definition template, we see the result of our alternate header work as shown in Figure 2.5. The code we implemented for the alternate header was very simple. It displayed an Information Hub logo bar above the menu. However, it need not have been so simple. It could have used DHTML drop-down menus or just about any other HTML elements that the client browser can understand. Figure 2.5. Using an alternate header. Overriding SharePoint JavaScript Functions with CustomJSUrlAnother noteworthy attribute of the Project element is CustomJSUrl. CustomJSUrl provides a quick way to add a JavaScript file to every page in the site definition. One of its more interesting uses is to override specific functions within OWS.JSaffectionately known as SharePoint's client-side API. This technique takes the form of rewriting the selected OWS.JS functions in a custom JavaScript file. Although this method will result in two valid functions with the same name, the functions in the custom JavaScript file will be run instead of those within OWS.JS. Of course, this override is a function of JavaScript and is not dependent on using CustomJSUrl. Therefore, you could replicate this functionality several ways. Instead of using CustomJSUrl, you could manually edit a SharePoint ASPX page or use the Content Editor web part on that page. Both methods enable you to inject a JavaScript function. Adding Menu Items to the Drop-Down List MenusIn the following example, we add a menu item to the DHTML drop-down menus for SharePoint libraries and lists. When selected, this menu item will send an email link to the selected list or library item. The resulting document library menu is shown in Figure 2.6 and is representative of the list, picture library, and form library menus. Figure 2.6. Email Link menu item added to document library. Of the various ways to accomplish this task, the easiest is to use the CustomJSUrl attribute. The modified Project element in MyFirstSiteDefinition is shown in Listing 2.7. Listing 2.7. ONET.XML Project Element Referencing a CustomJSUrl
The first thing you might notice is that the [% and %] symbols delineates .NET code and appears to function as the <% and %> symbols do in ASP.NET. If you are like me, you might immediately think that you could use the full ASPX object model within ONET.XML. Unfortunately, that is not the case. Only the simplest ASPX code is allowed. Furthermore, this code's results are cached within the ASPX application and reused until that application has shut down. In the previous case, the code inserts the locale identifier (LCID). If you are using the default English version of SharePoint, your LCID should be 1033. Currently, Microsoft has defined over 200 LCIDs, which are documented on Microsoft's Global Development and Computing Portal (http://www.microsoft.com/globaldev/reference/lcid-all.mspx ). The next tasks involve adding a menu item to the DHTML drop-down menu. Adding a menu item simply requires invoking the CAMOpt function (see Listing 2.8). However, that function must be passed the appropriate parameters and called from the appropriate place. Listing 2.8. SharePoint CAMOpt JavaScript Function Declaration
CAMOpt takes four parameters: the menu object, the display text string, the action string, and the image path string. The menu object defines the entire DHTML menu. The display text will be displayed in the menu. The action is a JavaScript action that will be performed when the item is selected. The image path specifies an icon for the menu item. In our example, we will use the A tag's HREF attribute to enable emailing. Thus, strAction could use JavaScript's window object to create an email message as shown in Listing 2.9. Listing 2.9. Example Use of CAMOpt's strAction Parameter
The strAction parameter need not trigger client-side applications. It could also interact with SharePoint or other server applications. For instance, we could have called a custom ASPX page through window.navigate. This custom page could have taken subject, body, and other querystring parameters to send an email through the Share-Point server's SMTP resources instead of Microsoft Outlook. As such, these drop-down menus offer a tremendous amount of functionality. Now the question is where to invoke CAMOpt. Because we want this functionality in both document libraries and lists, we need to extend the AddDocLibMenuItems and AddListMenuItems functions. It should come as no surprise that AddDocLibMenuItems adds items to the menu for document libraries and AddListMenuItems adds items to the menu for lists. We need to copy the AddDocLibMenuItems and AddListMenuItems functions from OWS.JS to OWS_MyFirstSiteDefinition.JS. Both of these JavaScript files reside in the C:\Microsoft Shared\web server extensions\60\TEMPLATE\LAYOUTS\1033 folder. The only change to the AddListMenuItems and AddDocLibMenu-Items functions is to call AddEmailLinkToMenu immediately before exiting the function. AddEmailLinkToMenu is a function that we will need to write. The insertion of AddEmailLinkToMenu is shown in Listing 2.10. Listing 2.10. Modified AddListMenuItems and AddDocLibMenuItems JavaScript Functions
Ultimately, AddEmailLinkToMenu (see Listing 2.11) appends an Email Link item to the menu using CAMOpt. However, the bulk of the work is determining the URL for the item and then formatting that information in a JavaScript statement that creates a new prepopulated mail message. The more interesting aspects of this function include the use of ctx, CAMSep, and itemTable. The ctx object retrieves the virtual path to SharePoint's images directory, which maps to C:\Program Files\Common Files\Microsoft Shared\web server extensions\60\TEMPLATE\IMAGES. CAMSep is a function that appends a separator to the end of the menu. The itemTable object defines the table row of the selected library or list item. Listing 2.11. AddEmailLinkToMenu JavaScript Function Definition
An example itemTable.innerHTML is shown in Listing 2.12. Although this was taken from a document library, it is representative of all lists and libraries. In the AddEmailLinkToMenu function, we used regular expressions to find the A tag's hrEF attribute. The URL referenced by hrEF was passed into the email message. Listing 2.12. Example Value of itemTable.innerHTML from a Document Library
Defining and Rendering Navigation with the <NavBars>NavBars specify the navigation bars that are rendered by the SharePoint Navigation web control. Listing 2.13 details the top navigation bar defined in ONET.XML. The results of this listing are shown in Figure 2.7. Listing 2.13. Default ONET.XML Top Navigation Bar
Figure 2.7. Default top navigation defined in ONET.XML. Navigation links can be added, modified, or deleted by modifying the appropriate NavBars section of ONET.XML. For instance, Listing 2.14 now includes an additional NavBarLink to Information Hub. The resulting navigation bar is shown in Figure 2.8. Listing 2.14. Modified ONET.XML Top Navigation Bar
Figure 2.8. Modified top navigation defined in ONET.XML. One of the first things you might have noticed is that Home is not defined in the navigation bar. That is because it is handled in another section of ONET.XML. That link is defined in the File section of ONET.XML and is more fully explained later in Table 2.11. Complex changes to the top navigation are not simple to implement. Although it is tempting to believe that the ASP.NET code embedded within the NavBarLink elements could be used as a mechanism for dynamic menus, this is not the case. As mentioned earlier, the top navigation is rendered with a Share-Point web control. The SharePoint web control retrieves the NavBar element with an ID defined in the LinkBarID. In the case of our site definition, this ID is 1002, so the web control retrieves the navigation as explained previously. Additionally, this ID must also be referenced in the appropriate Modules sectionwhich we cover later in this chapter. Listing 2.15. SharePoint Navigation Web Control to Render Top Navigation
<ListTemplates>: Specifying the Allowed Lists and LibrariesListTemplates defines the documents and lists as well as their properties for the site definition. Only the list types specified (through the ListTemplate elements) can be created for the site. For example, the XML specified in Listing 2.16 only enables document libraries to be created. This is further evidenced by Figure 2.9, which shows Document Libraries as the only list type. Listing 2.16. ONET.XML ListTemplates Definition That Allows Only Document Libraries
Figure 2.9. List Creation page with only Document Libraries allowed. Although other choices might appear on the page, such as Import Spreadsheet, you can only create list types listed in your ListTemplates section. In the current example, if you try to import a spreadsheet, it will fail because Import Spreadsheet is dependent on a Custom List typewhich isn't specified in ONET.XML. When restricting the available list types, be mindful that dependencies on these lists can trigger an error. For instance, both the Configuration and Modules sections can reference a list type that you have not listedhence denying its availability. If that happens, SharePoint will not be able to create your site, and the user will be presented with an error. If you truly want to create a default document library, such as Shared Documents, but do not want to allow the user to create other lists, you should consider using the Hidden attribute for ListTemplate. All the ListTemplate attributes are shown in Table 2.5.
Let's examine the use of Hidden and HiddenList. Let's assume that our site definition will create a document and image librarywhich will be discussed in the Configurations section. If we were also to modify our site definition as specified in Listing 2.17, we would make all instances of document libraries hidden and make the picture library list type hidden. This is evidenced by the screenshots in Figure 2.10, Figure 2.11, and Figure 2.12. Listing 2.17. ONET.XML ListTemplate Definitions
Figure 2.10. The hidden list template of Picture Libraries does not appear on the Create page. Figure 2.11. Shared Documents as a hidden list that does not appear to exist. Figure 2.12. Shared Documents as a hidden list that is still navigable. In Figure 2.10, we see that Document Libraries can be created. Furthermore, we see that even though Picture Libraries are a valid list type, they cannot be created through the Create page. This is because the Hidden attribute has been set to trUE for the list template. Because the document library list template is set with the Hidden list attribute, all instances of that list type will be hidden from the userbut they will exist. Figure 2.11, which shows all documents and lists, is noticeably vacant of our Shared Documents document library. However, it does existas shown in Figure 2.12. You might have noticed the DocumentTemplate attribute. If you are creating a document library, you should define the document template on which all new documents will be based. You reference this template through the DocumentTemplate attribute. The document template that you reference here is defined in the DocumentTemplates section. <DocumentTemplates>: Specifying the Default New Document for a Document LibraryHave you ever wondered how the New Document buttonas shown in Figure 2.13knows what document to create? How does it know to use a Word, Excel, HTM, or other template? Have you ever wanted to customize that fileperhaps with your organization's standard header? If so, you will be happy to know that all this is controlled through the DocumentTemplates element. Figure 2.13. Document Library Toolbar. If a user creates a new document library, the user specifies the template at the document library's time of creation. However, if it needs to be created at site creationas part of the site definitionit is mapped to the desired DocumentTemplate element. In turn, this DocumentTemplate element specifies a template file that resides as a physical file in your site definition folder. To specify the default new document for a document library created during site creation, the ListTemplate/@DocumentTemplate attribute is mapped to the matching DocumentTemplate/@Type attribute. In the ListTemplates code snippet shown previously in Listing 2.17, you will notice that the document library's DocumentTemplate attribute is specified as 101. In the DocumentTemplates element detailed in Listing 2.18, you will notice that the matching element with a type of 101 is a Microsoft Word file. That is how the document library list knows to create a Word document when the user clicks New Document. Listing 2.18. ONET.XML DocumentTemplates Definition
The DocumentTemplate element is defined in Table 2.6. All the attributes defined in the table are fairly straightforward. The only attribute that stands out is Default. It specifies the default document template to be used when creating a document library. This template is preselected when the user visits the New Document Library pageas shown in Figure 2.14.
Figure 2.14. Creating a new document library. The DocumentTemplateFile element specifies the actual file to be used. As alluded to earlier, this file could be of any type and could be seeded with some custom content. Such would be the case with a Word document that has the corporate stationary embedded in it. The DocumentTemplateFile/@Name attribute specifies the relative path to the file within the site definition. Listing 2.18 specifies the Word document template as doctemp\word\wdtmpl.doc relative to your site definition folder. In our example, this would map to C:\Program Files\Common Files\Microsoft Shared\web server extensions\60\TEMPLATE\1033\MyFirstSiteDefinition\doctemp\word\wdtmpl.doc. Conversely, the TargetName attribute creates a hidden virtual path to this file in the document library. In the Word document template case, it is Forms/template.doc. You can verify this by going to any document library that uses this document template, switching to the Explorer view, and navigating into the Forms folder to see template.doc. Thus, when the user clicks the New Document button, the user is actually loading the customized Forms/template.doc file.
<BaseTypes>: The Foundation for List and Library DefinitionsBaseTypes define the schema for the lists and libraries (see Listing 2.19). As mentioned earlier, the list base type is specified through the ListTemplate/@BaseType attribute. This attribute actually references the Base-Type/@Type attribute. BaseType attributes are defined in Table 2.8. Listing 2.19. ONET.XML BaseType Definition
The snippet in Listing 2.19 details part of the schema definition for document libraries. Because the functionality of lists is bound to their schemas, you should never remove field elements. For instance, if you removed the column that stores the name of the person who checked out a file, the built-in functionality for document libraries would suddenly break. There are five base types in SharePoint. Unfortunately, other base list types cannot be added. However, the custom list type can be augmented to provide the functionality desired. This is done through modifying a SCHEMA.XML, which we cover more fully in Chapter 3. SCHEMA.XML is designed to extend the functionality of the Base-Type element. In fact, the MetaData element is used in both ONET.XML and SCHEMA.XML. In ONET.XML, MetaData defines the base fields for a list. In SCHEMA.XML, MetaData can define additional fields, views, toolbars, forms, and a default description. It is worth mentioning that the FLDTYPES.XML file defines the allowable Field types. Thus, Field/@Type must be of a value defined within FLDTYPES.XML. FLDTYPES.XML should not be modified. We also recommend that you do not modify the BaseTypes section in ONET.XML. You should be able to modify SCHEMA.XML to effect any changes that modifying the BaseType would accomplish. <Configurations>: Defining the Site Definition TemplatesA site definition can contain multiple flavors of templateswhich are referred to as site definition templates. In fact, all eight default WSS templates (Team Site, Blank Site, Document Workspace, Basic Meeting Workspace, Blank Meeting Workspace, Decision Meeting Workspace, Social Meeting Workspace, and Multipage Meeting Workspace) are created from only two site definitions. The STS site definition contains Team Site, Blank Site, and Document Workspace definitions. The MPS site definition contains the Basic Meeting Workspace, Blank Meeting Workspace, Decision Meeting Workspace, Social Meeting Workspace, and Multipage Meeting Workspace. The snippet in Listing 2.20 details a few site definition templates in the MyFirstSiteDefinition site definition that we created earlier. As you might recall, we simply copied the STS site definition and therefore inherited all the templates from STS. So now you are thinking, if I have inherited all these templates defined in ONET.XML, why aren't they showing up on the Template Selection page when I create a new site? Well, the WEBTEMP Listing 2.20. ONET.XML Configuration for Team Site
In our example WEBTEMP The Module elements define files that are mapped into the site definition template. We will save our discussion of Modules for the next section. Furthermore, we have already defined the Configuration element in our previous discussion on WEBTEMP.XML, so we will not duplicate that discussion here. The List elements define the various lists that are created when the site definition template is applied. The seven user lists specified in the Lists element for Configuration ID 0 are shown in a newly created site with the template in Figure 2.15. The other three lists specifiedSite Template Gallery, Web Part Gallery, and List Template Galleryare special list types that are not exposed to the user through the Document and Lists page shown in Figure 2.15. As you might recall from Chapter 1, "Custom Templates," the Site Template Gallery is a document library for storing custom site templates, and the List Template Gallery is a document library for storing custom list templates. The Web Part Gallery stores WebPart DWP files. When you define your own List element, you will probably specify at least QuickLaunchURL, RootWebOnly, Title, Type, and Url. The complete set of List attributes is described in Table 2.9. It is worth noting that SCHEMA.XML can override the settings within ONET.XML. Thus, if you change the value here and are confused about why nothing happened, check SCHEMA.XML to see whether it is overriding your settings. Figure 2.15. The seven user lists created by our site definition.
If we wanted to create additional lists, we would have simply added another List element with the appropriate attribute settings. If we want to limit the lists that are created, we would remove the undesired List elements. If the QuickLaunchURL attribute has been specified, the specified URL is listed on the Quick Launch bar on the site's home page. You can specify any URLincluding one that does not link to the list. However, the Quick Launch URL can be reset to the correct one. This will happen if the user modifies the list's general settings to display it on the Quick Launch baras shown in Figure 2.16. This action will erase the URL you have specified as part of the List attribute and will replace it with the default All Items view. Figure 2.16. Quick Launch settings on the List General Settings page. The RootWebOnly attribute specifies that the list should not actually exist at the site level. Instead, it should exist at the root web of the site collection, and there should not be an instance at every site. A good example of a list that should exist only at the root web is the Web Part Gallery list. Obviously, you don't need to duplicate this list at every site. With that said, this attribute presumes that the root web list specified already exists. Thus, make sure the list exists before you use this setting. Lastly, URL specifies the virtual path to link to your list. If the Contacts list URL was modified from Lists to MyLists, as shown in Listing 2.21, then the virtual path to the Contacts list would change. Therefore, the URL to the list would be /MyFirstSiteDef/MyLists/MyContacts/AllItems.aspx, which is shown in Figure 2.17. Listing 2.21. ONET.XML List Definition
Figure 2.17. The URL changes in List are reflected here. <Modules>: Grouping Elements of a Site Definition Together to Use within ConfigurationsModules are simply functional file groups. As explained in the previous section, when you select a specific site definition template, you are actually selecting a specific Configuration element in ONET.XML. That Configuration element inevitably specifies several modules. The files specified in those modules are then deployed to the newly created site. Module attributes are defined in Table 2.10.
Module BasicsThe module in Listing 2.22 defines two pictures to be included with a site definition. Although the Name, Url, and Path attributes all have a value, they each have a different function. Listing 2.22. ONET.XML Simple Module Definition
The Name attribute specifies an identifier that can be used to reference this specific module. This would be used to reference this module from the Configuration section in ONET.XML as we discussed in the previous section. Name could be something very cryptic because it is never exposed to the user. The Path attribute specifies a folder relative to the site definition template's physical path. As shown in the Explorer screenshot in Figure 2.18, the images path is a child folder of the MyFirstSiteDefinition site definition and exists on the server's local physical hard drive. Figure 2.18. Physical path as defined by the Path attribute. Conversely, the Url attribute specifies a virtual path relative to an instance of the site. In the example shown in Figure 2.19, the image is mapped from the database to images virtual folder. Keep in mind that this is not an absolute path. It is a virtual path off an instance of the site definition template. Therefore, you will need to think a little more carefully when referencing these images from your various pages within the site definition because the image might or might not be available on /MyFirstSiteDef/Images/InformationHub.png or /MyFirstSiteDef/Subsite1/Images/InformationHub.png. Figure 2.19. Virtual path as defined by the Url attribute. Both the Path and Url attributes can support a syntax of a multiple-level folder structure. For instance, a Url value of "images/informationhub/2005" could just as easily have been specified in Listing 2.22. Fortunately, there is no need to build a multiple-level virtual path with multiple parent modules (for example, Url="images", Url="images/informationhub") as you would with a physical folder structure. The module files are actually mapped in the database, and their entire path is stored with them. The somewhat negative aspect of this is that you cannot browse their parent folders. When you try to browse to the images folder, you get a 404 error (see Figure 2.20), which gives the user the impression that there are no other child items herewhich is not the case. In our current scenario, there are two images within the images folder (JasonNadrowski.jpg and InformationHub.png). Figure 2.20. Images parent folder does not exist even though it contains pictures. From a best practice standpoint, you should match your physical path to the virtual Url as we have done with images. Making your virtual and physical paths the same helps to minimize confusion when someone new looks at the site definition or when you revisit it. The File element is the only child element that a module can have. The File element is described in Table 2.11.
In Listing 2.22, we only use the File element's Url attribute. This attribute name is a bit confusing because it is more in line with the Module's Path attribute than with the module's Url attribute. It defines the physical path relative to the module's Path attribute. We had simply specified the filenames with no path in the file's Url attribute because they resided within the images folder. Specifying true for the NavBarHome attribute signifies that Home on the top navigation bar (see Figure 2.21) will be linked to the File element. Because that navigation bar is used throughout the entire site, it is invalid to have more than one link for Home. Although you can have multiple File elements that have their NavBarHome attribute set to trUE within all of ONET.XML, you can only have one File element with its NavBarHome attribute set to trUE within a single Configuration element. Figure 2.21. Top navigation bar. SharePoint will cache most file types (GIF, JPG, PNG, etc.) when referenced with the File element, but ASPX files will not be cached. Thus, changes to an ASPX file will be immediately reflected in a site without an IISReset. However, changes to other file types, such as a JPG file, will not be reflected until SharePoint is restarted through an IISReset. Advanced Module Concepts: Views, WebParts, and Navigation BarsNow let's look at a little more intricate use of the Module element. The code snippet in Listing 2.23 details a Module for deploying the DEFAULT.ASPX file. In this listing, the File element has three additional child elements: NavBarPage, AllUsersWebPart, and View. Listing 2.23. ONET.XML Complex Module Definition
The NavBarPage element interacts with the navigation bar that we defined in the NavBars section. You might recall that although we defined navigation items for Documents and Lists, Create, Site Settings, and Help, we didn't define a Home element. You can add items to the top navigation bar in the Module. The first NavBarPage elementwith an ID of 1002binds DEFAULT.ASPX to the top navigation bar we defined within the NavBars section. It is no coincidence that the ID of the NavBarPage element (Listing 2.23) matches the ID of the NavBar element (Listing 2.13). If it didn't, SharePoint would become confused. The second NavBarPage elementwith an ID of 0adds Home to the top navigation bar. Additional Modules could be added to the top navigation bar, just as DEFAULT.ASPX was mapped to home, with the aid of NavBarPage. Those additional modules would need a unique ID for their NavBarPage element and their position. Their placement on the navigation bar would be controlled by the Position attribute. Position can be Start, End, or a number. AllUsersWebPart enables you to place a named web part on the web part page. In our example, we place the Image web part on the web part page. We just as easily could have placed the Members, Announcements, or any other custom web parts on the page. Initial configuration data for these web parts is usually passed through a child CData element. In our case, we specify the web part, its frame type, title, and an initial image. Keep in mind that the user could drastically modify these initial settings in the future. The WebPartZoneID and WebPartOrder attributes are valid in both AllUsersWebPart and View elements. These attributes control the placement of the web parts. The WebPartZoneID places the web part in a named zone, and the WebPartOrder specifies the order of the web part within a zone. In our example detailed in Listing 2.24, DEFAULT.ASPX has two zones definedLeft and Right. Listing 2.24. DEFAULT.ASPX Web Part Zone Declarations
The View element is very similar to the AllUsersWebPart. Instead of a named web part, the View element displays the contents of a list or library. This makes a lot of sense if you recall how web parts are added to a page through the GUI. As shown in Figure 2.22, the web part list that you select from includes not only web parts but also the lists and libraries of a site. In Figure 2.22, these lists include Announcements, Contacts, Events, General Discussion, and Links. Actually, these lists use the same web part class but with different connections to the underlying data source. The Announcements web part connects to the Announcements list, the Contacts web part connects to the Contacts list, and so on. This is exactly the same metaphor that the AllUsersWebPart and View elements use. Figure 2.22. Web Part List showcasing views of lists. In Listing 2.23, the View elements reference a List attribute and a BaseViewID attribute of 0. The List attributes reference 104 and 106. These List values were defined in the Configuration section of ONET.XML and correspond to Announcements and Events, respectively. Thus, a view of Announcements and Events will be added to the DEFAULT.ASPX page. The BaseViewID is the initial view selected for the web part. Those view IDs are initially defined within SCHEMA.XML. Figure 2.23 shows the initial views for an event list that originated from SCHEMA.XML. Through BaseViewID, the initial view of the Events list could be set to All Events, Calendar, or Current Events. Of course, this could always be changed through the GUI after the site has been created. Figure 2.23. Example Event List views. Only a subset of View element attributes is used within ONET.XML. SCHEMA.XML, which we describe later, more fully utilizes the View attributes. Table 2.12 describes all the View element attributes.
|
.CSS, which is located in the C:\Program Files\Common Files\Microsoft Shared\web server extensions\60\TEMPLATE\LAYOUTS\1033\STYLES folder. The specified CSS must exist in the C:\Program Files\Common Files\Microsoft Shared\web server extensions\60\TEMPLATE\LAYOUTS\1033\STYLES folder.
.LCID%]/viewlsts.aspx"> </NavBarLink> <NavBarLink Name="
EAN: 2147483647
Pages: 64