BEGINNING COMPONENTS FOR ASP PART 4 – DIFFERENT KINDS OF COMPONENTS

In this section we’ll describe a few of the commonly used categories.

Note that we’ve only categorized in this way for guidance. We’ve intended this as a useful way of understanding what can be done with components, but nothing more – there are no hard and fast rules about categories, and they are not mutually exclusive. A given component may fit into more than one of the categories we describe. If you’ve used many components in your ASP development, you’ll probably recognize some of these varieties, and may even be able to name some examples of each. If not, don’t worry – you’ll have seen plenty before long!

Generalized or Universal Components

Some components are of a generalized nature, and designed to be used in many different environments. Typical examples that display this behavior are the members of another group that you may well have met before: the set of ActiveX Data Objects (ADO) components that provide programmatic access to data stores.

The ADO components ship with all current Microsoft operating systems and data-aware applications, and they can be used from programming languages such as Visual Basic, Visual C++ and Visual InterDev. However, they are equally at home within applications that contain programming or scripting features, such as Microsoft Office, Windows Script Host (WSH), Internet Information Server (IIS), and so on. And, of course, we can use them from ASP – we’ll be focusing more closely on ADO and ASP in Chapter 4.

The Brick Calculator component we just saw (and which we’ll be building later in the chapter) is an example of a generalized or universal component.

Environment-Specific Components

Other components are designed specifically for use in a particular environment, and rely on some of the facilities of that environment in order to operate. The standard Browser Capabilities component that ships with ASP, for example, is designed specifically for use within IIS and ASP, and useless in any other environment. On the other hand, the Progress Bar component (which is supplied with Windows programming languages like Visual Basic and Visual C++) is totally unsuitable for use in IIS, as it provides a visual interface that is designed to provide feedback on a standalone workstation, as opposed to a web page served across a network or the Internet to a client.

We will come back to a discussion of client – server and n-tier architecture when we’ve completed our ‘categorization’. But for the moment, if you think about the client as being the machine that makes a request for the pages, and the server as a different machine where your ASP pages reside and get processed, with some kind of network in between, you will be able to follow the descriptions of components.

Visual Interface Components

The Progress Bar component we mentioned above also hints at a second way of classifying component types: by their support for a visual interface. Some components are more often described as controls, and the term is generally used to indicate that a component has some sort of visible representation that forms a significant part of its operation. The ActiveX Calendar control that ships with MS Office, the Structured Graphics control that ships with Internet Explorer 4+, and the FlexGrid control (shown here) that ships with Visual Basic 6.0 are also examples of components with visual interfaces.

image1 BEGINNING COMPONENTS FOR ASP PART 4 - DIFFERENT KINDS OF COMPONENTS

Because controls are usually implemented on client machines, as opposed to being run on the server as part of an ASP script, we will not be covering them in this book.

Business Rules Components

Business rules are the rules to which the operation of your component, application or system (or even your business) must adhere. These rules might involve checking that customers remain within agreed credit limits, that discounts are applied in a uniform manner, or that a manufacturing cycle is correctly scheduled. Business rules components are components that implement this kind of programming logic.

Because business rules components are chiefly concerned with the internal logic of the application, they often have no visual interface. However, there are many exceptions to this very general rule.

Transactional Components

Some applications require multiple, separate actions to take place in order to achieve the desired result. For example, if we’re updating a local database and then sending an order to a remote server, we want both actions to succeed: if the order request succeeds but the data update fails, our database won’t contain an accurate reflection of our orders. It is usual to implement a system that guarantees either that all of the required actions are successfully completed, or that none of them takes place. This is called a transaction, and we can create components that work with a transaction monitor to ensure the completion or complete undoing of each transaction. We’ll cover transactional components in Chapters 6 and 7.

Active Server Components

This is the category of components that this book is really about! If you’re reading this now then you probably don’t need to be told about the increasing popularity of Active Server Pages as a server-side programming language. This has produced an explosion in Active Server (sometimes called ActiveX Server) component usage. These components are specifically designed to run on the server under IIS, and to interface with ASP directly. They can provide better performance than pure script code, and encapsulate complex tasks. We’ll be looking at what programming features characterize Active Server components and how to write them in Chapter 3. Active Server components can be considered to form a sub-category of environment-specific components.

Utility/Commercial Components

This is the catchall that covers all the ‘leftovers’ from the other categories – for example, components designed to perform specific tasks within other components, and highly generic components that can be used in a variety of ways. You can make almost any block of code into a component, and so there is really no limit to the components you might create. Common examples are the commercial components that you can purchase off-the-shelf, such as registry access components, HTTP transfer components, and XML data parsing components.

Continued…