Datasheet

It would be convenient to have a single control that could be used to build all lists. This control could be
implemented in one of two ways: it could either accept a set of criteria for building a list of books, or
accept a list of book identifiers generated by some other part of the application. Either way, this control
would use the previously created book summary control to display the individual books on the list in a
standard way.
Throughout the application, customer information is gathered and displayed. Rather than make the user
work with several different formats for customer information, why not create a customer information
control? This control would work in two modes: data entry and data display. In the data display mode,
the control would retrieve customer information from the database and display it. In the data entry
mode, the control would accept customer information and do whatever validation is appropriate to the
user interface (ensuring the customer phone number is correctly formatted, for instance). Once the data
has passed validation, the control would take care of updating the database.
Here is a case where using a Web Part would be the best choice. If, for example, the Web page contains
multiple controls, how do these controls commit their changes to the database? For instance, the Web
page that lets customers order books might contain the control for entering customer information and
a control for entering sales order header information. If these controls interact with the database (or
middle-tier objects) individually, processing updates from the page could be very inefficient. The code
on the Web page could coordinate updates from the controls, but then you lose some of the benefits of
reusability that controls are supposed to provide. By taking advantage of the capability of Web Parts to
find other Web Parts on the page and communicate with them, the code in the Web Parts could coordinate
their updates. All the display-oriented Web Parts could look for an “update” Web Part on the page and
send their updates to that Web Part for processing.
In either display or update mode, the customer control would have a set of properties that would expose
the customer information to the application that’s using the Web Part. Figure 1-5 shows the customer
information Web Part in two different pages.
It’s not hard to see that in addition to the benefits of standardization, there exist significant opportunities
to improve the productivity of the person building or extending this application. When it’s time to build
a page that displays all the books for a specific customer, the developer who’s building the page can
start by adding the customer information control and the book listing control (which, in turn, uses the
book summary control). From that point on, the developer just needs to add any specialized code
required by the particular page.
Exploring the Different Kinds of Controls
Now that you’ve been introduced to the possibilities of Web Parts, custom controls, and user controls,
you may be wondering how to decide which control to use in which situations. In this section, I offer
guidelines on when you should use a user control or a custom control (remember that Web Parts are just
a kind of custom control). Nothing is free, of course, so you also see what costs you incur by picking
each type of control.
13
Creating Your Own Controls
05_57860x ch01.qxd 10/4/05 9:26 PM Page 13