Login | Register   
LinkedIn
Google+
Twitter
RSS Feed
Download our iPhone app
TODAY'S HEADLINES  |   ARTICLE ARCHIVE  |   FORUMS  |   TIP BANK
Browse DevX
Sign up for e-mail newsletters from DevX


advertisement
 

Exploit SharePoint List Definitions to Maximize Your Brand : Page 3

You can customize site definitions and add functionality to list editing tools, but if your branding and tools strategies aren't implemented in your list definitions, then your site isn't completely following those strategies. Find out how list definitions work, what their relationship is to site definitions, and how to change the appearance and the structure of the list.


advertisement
Controlling the Appearance of List Pages
There are two parts to customizing the appearance of list pages. They are the same two components you use when modifying a Web part page in a site definition. First, you can modify the page's ASPX file. In a site definition, this file has the name default.aspx. In a custom list, you have four or more pages to be concerned with. Each list has a form for: listing the entries, displaying a single entry, creating a new entry in the list, and editing an entry in the list. However, the process for these pages isn't any different than for the default.aspx page in the root of the site definition. It's all about manipulating the ASP.NET code (if you read "A Sensible Framework for SharePoint Intranet Navigation, you may want to add a few new zones on your pages—including your list pages—so that you have more flexibility in the appearance).

The second part of the process, which involves getting your custom Web parts to appear on the page along with the existing controls that create the user interface, involves modifying the schema and adding a few nodes.

By default, SharePoint will place a ListFormWebPart on each of the form pages. The Forms\Form node itself indicates that the ListFormWebPart should appear. However, in addition to the ListForm Web part, you can also add other Web parts. One example of this, in Windows SharePoint Services' out of the box definitions, is in the ISSUE list in the STS definition. It includes a Forms\Form\WebParts node that, in turn, contains two <View> nodes. These nodes define two views that appear on the bottom of the page. These views show the related issues in the list.



Another node you can add to the Forms\Form\WebParts node of the SCHEMA.XML is an AllUsersWebPart node. This node can contain any Web part you want to add to the page. One good use of this is to add text above an entry form to help explain the purpose behind filling out the information or how to fill out the fields. For example, you'd create some simple instructions for filling out the contacts record by adding the content editor Web part to the default page for the site, entering the text you want, and then exporting it and adding it to SCHEMA.XML. In the interest of brevity, the DWP added at the top of the contact's new entry form is available here.

Integrating this into the SCHEMA.XML is done by the following procedure. This example uses the TESTCONT\SCHEMA.XML:

  1. Locate the <Form> node or <View> node of the form or view to which you want to add the Web part. For this example, locate the third <Form> node in the \List\MetaData\Forms path of the XML. This node should have a type of NewForm.
  2. Add a <WebParts> node under this <Form> node. In some views or forms this node may already exist. This is fine. For this example, however, the node is missing.
  3. Add a new <AllUsersWebPart> node under the new <WebParts> node.
  4. Add two attributes: a WebPartZoneID attribute with a value of "Main" and a WebPartOrder attribute with a value of "0". These tell the Web part where to go on the page. Note that this information is also included in the DWP file itself.
  5. Under the <AllUsersWebPart>, add a CDATA node which is everything between the quotes here: "<![CDATA[ ]]>".
  6. Into this CDATA node, add the contents of the DWP file minus the first line which identifies the DWP file as XML.
  7. Remove the <!CDATA[ ]]> wrapper from around the <Content> node in the content editor Web part. XML doesn't allow for nested CDATA nodes, so the inclusion of a CDATA node in the DWP will cause problems.
  8. Save the file.
  9. Perform an IISRESET.
  10. Create a new list of the type that you were working on and verify that the Web part appears. Figure 2 shows what a new "test" list looks like.

Figure 2. A New "Test": The results of adding a content editor Web part to the new form of the contacts list.

If you need multiple Web parts or you want to add a Web part to every form, you simply repeat the process for any Web part that you want to add. The real power of this technique is when you couple it with removing all of the built in Web controls that are on the pages. They can be easily wrapped and added as Web parts to Web part zones. See the article "Wrapping Web Controls in a SharePoint Web Part" for how to wrap a Web control—like the SharePoint Web controls (you can also look at the blog post "Picking up the SharePoint Services Navigation Controls for a specific example and code). In essence, you make the entire site definition driven by Web parts so that you can change the entire appearance of the Web site in one fell swoop when you're ready later. Check out the article, "A Sensible Framework for SharePoint Intranet Navigation," to learn more about this approach.



Comment and Contribute

 

 

 

 

 


(Maximum characters: 1200). You have 1200 characters left.

 

 

Sitemap