Datasheet

Undoubtedly, the user community for your application will contain a variety of users, many with special-

ized needs. It’s entirely possible that every user has a unique set of needs. As a result, different users may

assemble the Web Parts that you’ve built in different ways. Instead of building a single application that

must meet the diverse needs of all of your users, you build the Web Parts that your users need, and let your

users each build a set of unique applications that meet their needs. Instead of building a single application,

you enable the creation of an infinite number of applications, each tailored to its user. This is the ultimate

goal of user customization: Each user builds a custom application for himself. With customization, each

user sees her own custom version of the underlying application, as shown in Figure 1-2.

This is X-customization: eXtreme customization. But you don’t have to go that far in order for Web Parts

to be useful to you. If you do allow users to customize your application, it’s likely that you’ll support

only limited customization of restricted portions of your application. And, in all likelihood, rather than

each user building a unique application, a single customization will be implemented by many users in

the user community.

But you can still consider X-customization as the ultimate goal of Web development — empowering

your users with the tools they need to meet their goals.

Customization doesn’t have to be limited to your application’s users. You probably already recognize

that you have different kinds of users in your user community. As a result, you may be planning different

parts of your site to serve different user types. As part of this design process, you can create a series of

roles for your application, where each role represents a different segment of your user community. The

next step is to create a set of controls that can be assembled in different ways to create the pages that make

up your application. You can then go one step further and, after adding your controls to the Web page,

use the controls as Web Parts and customize them for various types of users. The final step is to assign

users to roles so that when a user logs on, she receives the pages designed for her role.

Chapter 1

Piggy Banks and Lego Kits

What’s the difference between building a standard application and building a cus-

tomizable solution? Let’s say that you have some spare change rattling around in a

drawer (or, worse, in several drawers). The obvious solution is to go out and buy a

piggy bank. The piggy bank is a great tool for collecting and holding coins— but that’s

all it can do. Most piggy banks don’t even do a very good job of holding paper money,

let alone all the other things that you might want to save.

So instead of buying a piggy bank, you could buy a Lego kit. With a Lego kit you can

build your own piggy bank — perhaps even figure out how to build a bank that works

well with all the different things that you want to save. You can also build a tower, a

plane, a car, and anything else that you can think of.

In addition, different Lego kits have different building blocks. The greater the variety

of Lego building blocks available to you, the greater the variety of things that you can

build and the easier it is to build specific items (a car is considerably easier to build if

your kit includes wheels and axles, for instance). Within any application domain,

domain-specific tools are more useful than general-purpose tools.

With Web Parts, your job is to provide your user with a set of building blocks that your

users can build solutions with. And, besides, who doesn’t enjoy playing with Legos?

05_57860x ch01.qxd 10/4/05 9:26 PM Page 8