Datasheet

Beyond Reusability with Web Parts
Through customization, Web Parts give you the opportunity to gain a new and more challenging class
of benefits: you can create Web Parts that end users can add to their pages in order to create their own
solutions. Think of Web Parts as reusable visual tools (rather than just visual components): Web Parts
are tools that users employ to meet their goals. When you create a user control or a custom control you
design it to help you and other developers solve problems in creating applications. With Web Parts you
create controls designed to let end users solve problems, often in situations that you may not have even
thought of.
This opportunity is challenging because it’s difficult to predict all the ways that users will find to employ
a genuinely useful Web Part. If building a reusable visual tool isn’t enough of a challenge, you can also
offer users the capability to customize your Web Part to meet their needs. In addition to adding your
Web Part to a page, users can also modify the way that your Web Part behaves.
Developing with Web Parts isn’t about what you can do for your users. Web Parts are about what you can
allow your users to do for themselves — how you can empower your users. You can give users the ability
to add Web Parts to pages, remove Web Parts from pages, move Web Parts from one location to another
on the page, customize the Web Parts on a page, and join Web Parts together so that they can pass infor-
mation between themselves. Users can perform all of these activities through your site’s user interface—
other than a browser, no additional tools are required. So, in addition to building applications, you can
provide the tools that allow users to build their own solutions.
Allowing Customization with Web Parts
Initially it may seem that incorporating Web Part tools into your application isn’t all that different from
incorporating Web Part components into your page. When you decide to use a control as a Web Part, it may
appear that all you’ve done is delay when the control will be incorporated into a page or when the control’s
properties will be set. For instance, instead of adding your control to a page at design time, you’ve delayed
adding the control to the point when the page is being used at run time. You may be thinking that all that’s
required is some additional planning to ensure that your page will work correctly no matter when controls
are added. You may even be thinking that all you’ll really need to do is add some more error handling to
your code in order to deal with conditions that may not have been considered at development time. If you
do, then you’re missing the point of Web Parts.
Here’s the point: Incorporating Web Parts into your application development makes it possible to create
a new kind of Web application. SharePoint, where Web Parts first appeared, was designed to empower
users to build solutions that met their needs. With Web Parts now part of the ASP.NET developer’s
toolkit, you (and every other ASP.NET developer) also have the ability to empower your users. Instead
of just designing an application to perform some task, you can consider the entire range of activities that
your users need to perform and build tools that support those activities in any combination. Instead of
delivering a rigid system that implements your design, you can build a discrete set of tools that allows
users to meet their own needs. As your users’ needs change and grow over time, they can call on your
tools to deal with those changes.
7
Creating Your Own Controls
05_57860x ch01.qxd 10/4/05 9:26 PM Page 7