However, with that power and flexibility also comes the need to keep track of an enormous amount of detail. For example, if were you to add an input button to a custom rendered control, you'd need to insert the correct HTML to describe the button within the response stream heading back to the client. Things get even more difficult when you decide to add more complex controls like selection controls that may need to track collections of items. Even though input buttons and selection controls are easy to describe in HTML, we've seen that ASP.NET already includes server-side control classes that render the correct tags. The standard ASP.NET controls greatly simplify UI programming for Web forms.
Composite controls take advantage of these server-side controls that have already been written. Composite controls are composed from other controls. To illustrate the utility of composite controls, imagine you're working on a number of projects whose login screens require a similar look and feel. On one hand, you've already seen that it's fairly easy to build Web forms in Visual Studio. However, if you run into a situation requiring the same group of controls to appear together in several instances, it's pretty tedious to recreate those pages repeatedly. ASP.NET solves this problem with composite controls.
If you need common login functionality to span several Web sites, you might group user name/password labels and text boxes together in a single control. Then when you want to use the login page on a site, you simply drop the controls en masse on the new form. The controls (and the execution logic) instantly combine so you don't need to keep creating the page over and over.
ASP.NET 2.0 now includes a set of login composite controls, so you don't need to write new ones from scratch. However, they are mentioned here because they represent an excellent illustration for the power of composite controls.
Let's begin by looking at custom composite controls.