Wrox Professional Web Parts and Custom Controls with ASP.NET 2.0 phần 3 potx

It would be helpful, then, if the custom controls were presented to the developer in a way that reflects

these functional groups rather than just as a list of custom controls in a DLL.

However, these custom controls reflect the requirements for a single site — the book site. It’s not hard

to imagine that the organization supporting the book site might also support sites selling music CDs,

DVDs, and other entertainment products. Because these kinds of products have different information

needs than books, these sites will use different custom controls to display product information and to

search for products. Furthermore, a site that loads the DVD-enabled versions of the custom controls

won’t use the book-enabled versions. As a result, it makes sense to create separate DLLs for the DVD,

CD, and book custom controls. This will result in separate projects for the book, CD, and DVD sites’

custom controls, for instance.

The customer information custom control has different considerations, however. The customer information

used on one site is the same for all the sites because customer information is defined at the organization

level, rather than the site level. As a result, the customer custom control will be common to all of the sites.

It makes sense then, to have the customer information custom control in a project by itself so that it will be

compiled into its own DLL. With the custom information control in its own DLL, any of the sites can load

the customer custom control without loading other custom controls that the site won’t use.

As this case study suggests, you are always looking at the tradeoffs between keeping your DLLs small

while ensuring that loading one DLL will also “pre-load” other custom controls that your application

will likely be using.

While it would certainly be helpful if developers using your custom controls read your documentation

(you did write the documentation, didn’t you?), developers prefer to figure out how to use your custom

controls by looking at the IntelliSense drop-down lists and the Object Browser. As you develop multiple

DLLs, you need to start thinking about how you can organize the Web Parts when presenting them to

developers in IntelliSense and the Object Browser.

Naming Conventions

The first step in providing a level of organization beyond the library level is to use a naming convention

for your custom controls and their libraries that reflects the functions that are important to the control’s

users — the developers building Web pages. For the bookstore site, names that describe the function of

the part (such as BookSearch, BookDetailDisplay, and CustomerSearch) are more useful to developers

than, for instance, names that describe the order that the parts were developed in (FirstWebControl),

how recent the custom control is (NewBookSearch), or the developer who created the custom control

(MyWebControl — which is what’s used in this book).

Having said that, the major benefit that you can pass on to your users is to be consistent in the way that

you name your custom controls (for example, the descriptive names used earlier specified the type of

data first, and then the activity performed). If you put out new versions of your custom controls, you

should either create a new library or append version-related information to the end of the name (such

as BookSearchV2).

Namespaces

The next step is to consider using namespaces, especially if you have (or expect to have) a project with

many custom controls. Namespaces allow you to organize the custom controls within a project into

meaningful groups — meaningful from the point of view of the developer using the custom controls. For

the custom controls that support the bookstore Web site, namespaces that divide the custom controls into

Book, Customer, and Site groups would reflect the way that developers think about the controls.

63

Creating Custom Controls

08_57860x ch03.qxd 10/4/05 9:20 PM Page 63

It may appear, in the IntelliSense lists, that your classes are organized into groups by the name of their

project/DLL. That’s an illusion. Classes are always organized by the namespaces that they belong to. By

default, however, the namespace for each project is set to the name of the project. It is because of these

default values for namespaces that it appears that controls are organized into groups by project name.

By overriding the default namespace for a project you can provide a higher level of organization and

group controls in different projects together.

You may want to have custom controls that have been created in different projects presented to the devel￾oper as a group. For instance, if there will be multiple projects to support the book, CD, and DVD store

sites, a different way of organizing namespaces might make sense. Instead of dividing the custom controls

into Book/Customer/Site namespaces, it might make more sense to divide the custom controls into

Search/Information/Page namespaces with the Search custom controls from all the Web sites sharing a

namespace. Within the Search namespace, the custom controls could be divided into Book/Music/DVD

namespaces.

Dividing your custom controls among libraries is a technical decision — you want to group the custom

controls to reduce the number of DLLs that will be loaded at run time. The organization of your custom

controls by Namespace is a design decision — you want to group your custom controls in a way that

makes life easier for the developers using your custom controls. As with your naming convention, the

namespace-based organization should reflect the way that developers think about using your custom

controls.

The number of possible conventions is large. One large conglomerate uses CompanyName.ProjectArea

.ComponentArea.ComponentSubArea.EntityName. (For example, it assigns names like DVDSales

.CustomerMgmt.UserInterface.Input.Address.) Other companies use naming conventions that help

organize their source code in whatever source code repository they use. The company in the last example

uses the parts of the control’s name as subdirectories within SourceSafe. This means that the code for the

Address custom control is found in a subdirectory nested five levels deep but it also means that the source

code for any given control is easy to find — provided that developers understand the convention and

follow it when naming their controls. It would be an exaggeration to say that the naming convention that

you use doesn’t matter (a good naming convention embeds key information about the control in the name),

but the most important part of a convention is that it be used consistently.

The samples created for this book are in two namespaces: VB (for WebControls written in Visual Basic

2005) and CS (for the C# versions). This division reflects an important distinction for the audience of a

.NET programming book: C# developers will want to use the versions of the custom controls written

in C#; Visual Basic 2005 developers will want the Visual Basic 2005 versions. Coincidentally, this name￾space division reflects the division of the libraries: The Visual Basic 2005 custom controls and the C# cus￾tom controls are in two different libraries. These two namespaces are nested within the PHVWebControls

namespace, which causes the two libraries to be displayed together in the IntelliSense drop-down lists.

This namespace represents the total audience, represented by the readers of this book.

To set the root namespace for a Visual Basic 2005 project in Visual Studio 2005:

1. Double-click the My Project entry in Solution Explorer to open the Property Pages for the

project.

2. On the Application tab, set the Root namespace text box to the namespace you want to use for

your project (see Figure 3-3).

64

Chapter 3

08_57860x ch03.qxd 10/4/05 9:20 PM Page 64

Figure 3-3

For C# projects:

1. Double-click the Properties entry in Solution Explorer to open the Property Pages for the project.

2. On the Application tab set the Default namespace you want for the project (see Figure 3-4).

Figure 3-4

65

Creating Custom Controls

08_57860x ch03.qxd 10/4/05 9:20 PM Page 65

You can also get to these property pages by right-clicking the project (either Visual Basic 2005 or C#)

and selecting Properties from the pop-up list.

Namespaces within the root namespace are set inside the code files for the custom control by using the

Namespace keyword in Visual Basic 2005 and the namespace keyword in C#. The following Visual Basic

2005 code shows the definition of a namespace called VB within a Visual Basic 2005 class file:

Namespace VB

Public Class BookDetail

Inherits System.Web.UI.WebControls.WebControl

End Class

End Namespace

For C#, the namespace is set like this:

namespace CS

{

public class BookDetail : System.Web.UI.WebControls.WebControl

{

}

}

Extending Existing Controls

The rest of this chapter shows you how to build all the parts of a custom control. However, you don’t

always need to take on that level of complexity. Often what you want to do is change one or two features

of an existing control, or just add a new method. For instance, if you haven’t databound the ASP.NET list

box, adding items to it can be awkward. As an example, this code adds some Canadian cities to a list box

in Visual Basic 2005:

Me.ListBox1.Items.Add(“Regina”)

Me.ListBox1.Items.Add(“Ottawa”)

Me.ListBox1.Items.Add(“Winipeg”)

This isn’t the most awkward code in the world, but it would be convenient to have a method that would

add all of the items in a single statement, like this in Visual Basic 2005:

Me.PHVListBox1.AddList (“Regina,Ottawa,Winnipeg”)

It’s very easy to take an existing control and add a new method to it. Because this control is just modify￾ing the existing list box control, simply have your custom control inherit from the ListBox object. That’s

what this Visual Basic 2005 code does:

<DefaultProperty(“Text”), ToolboxData( _

“<{0}:PHVListBox runat=server></{0}:PHVListBox>”)> _

Public Class PHVListBox _

66

Chapter 3

08_57860x ch03.qxd 10/4/05 9:20 PM Page 66