Conclusion

In this chapter, I presented an overview of Web Parts and how they are used and controlled on a Web page. Web Parts are not appropriate for every application, perhaps not even most, but they are perfect for some types of applications. If you are creating portal Web applications, with lots of utility-type functions on a single page, Web Parts are ideal. You can make all sorts of Web Parts available, allowing users to personalize the page so that they always see exactly what they want to see, in the order they prefer. There are, of course, some limitations to what users can do. In general, they can make Web Parts visible or invisible and move them around, but only within the constraints of the developer's design. Web Parts can be dragged and dropped only into Web Part zones; a Web Part zone must exist on the page before a user can drop a Web Part into it.

One significant aspect of using Web Parts has not been addressed in this chapter. Rather than using individual controls as Web Parts, you will often want to create custom controls that act as Web Parts; this lets you do a variety of special things, such as allow users to edit information in the Web Part. In addition, unlike the default title bar text "Untitled" that results from dropping standard controls into a Web Part zone, custom Web Parts can have defined titles. User controls can also be used as Web Parts, and by overriding a single interface, many of the Web Part properties can be set. Building custom Web Parts and using user controls as Web Parts will be covered in Chapter 6, "Custom Controls."

Next, in Chapter 5, you will learn all about data binding. Virtually all Web sites rely on data from a database to customize content for the user. Data binding makes it all happen. ASP.NET 2.0 provides some powerful new controls that allow the developer to do more with less code. Still, when working with data, you might find yourself occasionally working with code to make the magic happen.