Datasheet

When you build an application, you are faced with decisions on what user interface will work best
for your users. For instance, the application’s designers may have decided not to display book detail
information on the same page as a book list. The site’s designers may have thought the amount of
information on a page with both a list and detailed book information would be overwhelming — for most
(but not all) users. So, while users can generate a list of books with summary information, when the user
wants to look at detail information he has to click a button and go to a new page. To continue to work
through the list, users must click a button to return to the list. The result is that users “ping-pong” back
and forth between the list and detail pages. For many users, this is the optimal design.
But there may be users out there who resent having to click an item in a book list in order to go to a new
page that displays the detail information on a book. They would prefer to have the list display the detailed
book information, rather than just the summary information. Given access to the controls already dis-
cussed, using those controls as Web Parts would let users build this detailed list page by dropping the
detail book Web Part onto a page with the listing control. Look again at Figure 1-4: The top portion shows
the standard book listing using the detailed book information Web Part, while the bottom portion
illustrates the same listing, but now using the summary book information Web Part.
With Web Parts, any user can build a page to meet her unique needs, the only limits being the toolkit of
Web Parts that you provide. For instance, the application probably has a page that displays all the books
purchased by the current customer. The user just navigates to the page to see the books she’s bought.
However, it’s not hard to imagine that customers might want to list all the books purchased by their
company or some other buying entity that they have permission to view. To get this list by using one of
the application’s built-in lists, the customer has to navigate to the page, enter the name of the organiza-
tion into the search criteria, and then generate the list. You could expand your application to hold the
customer’s various affiliations and automatically display books purchased by affiliated organizations—
but where does this stop?
Instead, you could allow your users to build a dedicated search page. The first step would be to enhance
the customer information control so that the user can set the properties on the control, including the
customer name. A user could then drag the customer information control to a page and customize the
control by setting the customer name to some buying entity that they are allowed access to. With that
done, your user could drag the listing Web Part onto the page and connect it to the customized customer
information Web Part. The listing Web Part would now display the books purchased by the entity
entered in the customer Web Part. The user could redisplay the list just by navigating to the page.
As this example indicates, you may want to create Web Parts whose sole purpose is to support user
customizations. For instance, the application has several places where users can enter search criteria for
listing books. However, it may not make sense to build a separate control for entering search criteria
or listing books because there’s no opportunity for reuse. It may be that every search page supports a
different set of criteria and each list has a unique format for displaying the books found in the search. In
addition, this version of the application uses only the summary book information and detail book infor-
mation Web Parts.
Even though there’s no opportunity for reuse, it may still make sense to create controls just to support
customization. To create opportunities for customization, you could create sets of Web Parts for:
❑ Entering search criteria: One control might provide a limited number of search criteria (just
author and title), another control might provide an extensive list of options familiar to the general
audience (author, title, publisher), while another control might offer options only of interest to
collectors (allowing the user to specify particular editions or publication dates, for instance).
17
Creating Your Own Controls
05_57860x ch01.qxd 10/4/05 9:26 PM Page 17