Microsoft Office Tutorials and References
In Depth Information
Under the Lists And Libraries category, by default, are the following web parts (indicating that
they are existing lists or libraries on the site): Announcements, Calendar, Links, Shared Documents,
Site Assets, Site Pages, Tasks, Team Discussion. These are the lists and libraries generated by the
Team Site template when the site was built. If you aren’t using that template for your site, you might
not have exactly the same items listed (and you won’t have the wiki page as your home page either).
Under the Content Rollup category are the Relevant Documents and XML Viewer web parts.
Relevant Documents The Relevant Documents web part makes sense as a roll-up web
part—not only is it filtered to show just the documents relevant to the account that you are
using to log into the site, but it actually aggregates or “rolls up” all the documents from all
the site’s libraries that might be relevant to your account. This means that any document you
are working on in any library will be listed, unlike the Shared Documents web part, which
displays all documents for that library only. And since documents can be considered content,
well, I guess that makes it a good thing to have in this category. This web part is one of two
that I consider “user-specific” web parts; both personalize any page they’re on by filtering its
contents by the account logged in.
XML Viewer The XML Viewer web part, however, doesn’t seem to be a natural it for the
title of this category. What it is supposed to do is take XML, translate it to XSL (using XSL
translation, XSLT), and then show the data. I guess, if you work with the right code, you
could have it do some content roll-up. I’ve used the XML Viewer web part to display the
result of a little HTML or XML script I might need (like a Google gadget or something). It’s
not necessarily what it’s meant for, but as an admin, I sometimes have to go with what works.
The Forms category contains only one web part, HTML Form.
HTML Form This web part is very simple and powerful. What it does is flatly demonstrate
a web part capability that a lot of people still don’t use—web part connections. When two
web parts (or more) are on the same page and they have content displayed that they both
have in common, you can connect them by that content. When web parts are connected, one
web part can be used to filter the data of another web part.
As is often the case with lists, one list will have a unique record for something, such as a
customer, and another list will have a bunch of records, such as sales, related to each customer.
If you use a lookup field in the sales list for the customer field so that the data-entry person
only needs to select a customer name in that field rather than type it in, then those two lists
are connected (or related, if you will). In that case, if you put web parts for both lists on a
page, you could connect them using their common fields. Then you could select a customer
from the customer list, and it would filter the display of records from the sales list to show
only the sales that relate to that customer.
What an HTML Form web part does is even easier. It gives you only a field to type in and a
Go button. When you add it to a page, you have to configure it to connect with some other
List View web part on the page, specifying one of its fields to filter. Then, to use the form, you
just type in a word (exact match only), and it will look at the connected list and return only
the records that have a matching value in their field.