Home arrow ASP arrow Page 3 - Sample Chapter: Beginning Active Server Pages 3.0

Sample Chapter: Beginning Active Server Pages 3.0

Although ASP.Net is now the "in thing", a person with ASP 3.0 skills is still in high demand. Today Joe's going to take a look at a sample chapter from the hugely popular "Beginning Active Server Pages 3.0" title, which is published by Wrox.

Author Info:
By: Joe O'Donnell
Rating: 5 stars5 stars5 stars5 stars5 stars / 41
May 23, 2002
  1. · Sample Chapter: Beginning Active Server Pages 3.0
  2. · Objects, Properties, Methods and Events
  3. · Return Values
  4. · Programming with Objects
  5. · Retrieving a Property
  6. · What is the Active Server Pages Object Model?
  7. · Using the Object Model as a Road Map
  8. · Conclusion

print this article

Sample Chapter: Beginning Active Server Pages 3.0 - Return Values
(Page 3 of 8 )

In addition to passing parameters to a method, the method can also return information to us. The value returned by a method is (rather conveniently) called a return value. If a method has a return value, then it will pass information back to us. This information could have a number of purposes. For example, the return value might be an indication of whether or not the method completed successfully. Alternatively, the method could also pass back the results of some processing that it did for us. It can even return another object as a result.

As the user of an object, we can decide whether we want to do anything with the return value. If the information is pertinent to what we are doing, then we can capture the return value and do something with it later. If we do not care what the return value is, we can just ignore it and continue with our work.

Just as the methods of the telephone object can have parameters, we can identify those methods that pass return values (and these can be passed as parameters to other methods), and what those values mean.

Method Name

Return Value


True (if call completed successfully)
False (if call failed)


No Return Value


True (if telephone was hung up successfully)
False (if not)


True (if card was accepted)
False (if card was not accepted)


No Return Value

We have now looked at two of the three characteristics of an object. The properties and methods of an object are ways that the user of the object can communicate with the object. Now, what if the object needs to communicate with the program that created it?

As an example, consider what happens when our telephone receives an incoming call. The fact is that it needs some way of telling us to answer the call. How will the telephone communicate this information to us?

Again, it's possible for the telephone object to have a property (called IncomingCall, perhaps) that was set to 'True' whenever an incoming call was present. However, there are two disadvantages to this. First, it would require the user of the telephone object to check this property on a regular basis. Second, the user would require a great deal of knowledge of the inner workings of the object, which isn't ideal.

What is needed is a way for the object to tell the user that something has happened. The mechanism for this is called an event. An object generates an event whenever something of interest happens. In our telephone example, when the telephone receives an incoming call it tells us so in the form of an event – we'll call it the IncomingCall event. (On most telephones, this particular event takes the form of the telephone ringing.)

The telephone object would generate an IncomingCall event every time an incoming call is received. In a physical phone, the ringing sound is the phone notifying you of the IncomingCall event. When the user receives this event, it can execute the 'Answer' method (pick up the handset), and begin the call. This frees the user from having to check regularly for incoming calls: the event is designed to notify the user just at the appropriate moment.

Just like methods, events can have parameters. These parameters can hold specific information about the event. For example, if our telephone supports CallerID – a feature that reveals the identity of the incoming caller – then the IncomingCall event could include a parameter that contains the telephone number of the incoming caller.

Here is a list of the events that our telephone object will generate, along with their associated parameters:

Event Name



Incoming CallerID information


No Parameters

There are a couple of useful pieces of terminology that are often used in this context. When an object generates an event, the object can be said to fire the event. When the object has fired the event, we say that the user must handle the event.

Synchronous vs Asynchronous
One of the advantages of working with objects and events is that it awakens us to the concept of asynchronous programming. First off, let's look at the definitions of synchronous and asynchronous.

These terms refer to how two separate actions are related to each other. If the first action must be completed before the second one begins, then these two actions are said to be synchronous. If the second action can begin at any time, no matter what the status of the first action, then these two actions are said to be asynchronous.

We've already discussed what it would be like if we our objects didn't support events. For example, to detect an incoming call, you would need to constantly check the value of some property to see whether an incoming call was waiting. While you're performing these frequent, regular checks, you would be unable to perform other tasks dependent on the outcome of that task. This is an example of synchronous activity. For example in the real world you might be waiting for a telephone call from a friend to let you know what time you should meet them. You can't go out until you've arranged a specific time. It's the same in programming. Your program could be waiting on a WaitForAnIncomingCall method in a While ... Wend loop, and it could be stuck there until the call was detected, refusing to return control to the main body of your program.

With events, we can have asynchronous activity. By having an event handler that is called when the object fires the 'IncomingCall' event, we can perform other tasks (for example, making an outgoing phone call) without having to devote any effort to monitoring the incoming call status. Our event handler code will be dormant until such a time as it detects the 'IncomingCall' event, and then sets about dealing with the incoming call.

This is not to say that all synchronous is bad and all asynchronous is good. You will see many instances in the real world where it makes sense to use a synchronous activity to perform a certain type of processing. Likewise, we will also see instances where an asynchronous activity is not an optimal way of dealing with an event.

One great thing about objects is that you don't have to understand what's going on underneath the shell, to know how to operate them. With our telephone we don't need to know how our voice is projected from the phone, down the wires to the nearest exchange, and how from there it gets to our intended destination. This is all hidden from us. It's the same in ASP – you don't need to know how the object was programmed, for example, in C++ or VB (objects can be created in many languages), to be able to interact with it. The concept of a user of an object not being concerned with the inner workings of the object, is known as encapsulation. For example, when you use a telephone to answer an incoming call, all you need to do is pick up the handset. You don’t need to know how the transistors are connected to each other inside the telephone. This is the equivalent of executing the Answer method. You do not need to know what's going on underneath – that's all encapsulated within the Answer method. This is an example of encapsulation.

One advantage of encapsulating the workings of an object within a method is that the implementation of the method can be changed without having to adjust the client. For example, suppose the phone company decides to change the way that an incoming call is answered. Without encapsulation, all of the users of the telephone object would have to be adjusted to support this new way of answering the phone. Instead, by encapsulating these new steps within the Answer method, the actions of the client never need to be changed: with either system, all the client needs to do is execute the 'Answer' method. Not only does encapsulation make the telephone user's life easier; it allows the developer of the telephone object to change the implementation at any time.

Moving On to Programming
Now that we have a basic understanding of what an object is, we can move on to looking at how programming concepts have changed from traditional methods by using objects. When working with objects in software development, we will create objects that have properties, events and methods. We can use these three attributes to describe physical objects and abstract concepts. Either way, the programmatic object will allow us to interact with it through its properties, events and methods.
blog comments powered by Disqus

- Central Scoreboard with Flash and ASP
- Calorie Counter Using WAP and ASP
- Creating PGP-Encrypted E-Mails Using ASP
- Be My Guest in ASP
- Session Replacement in ASP
- Securing ASP Data Access Credentials Using t...
- The Not So Ordinary Address Book
- Adding and Displaying Data Easily via ASP an...
- Sending Email From a Form in ASP
- Adding Member Services in ASP
- Removing Unconfirmed Members
- Trapping HTTP 500.100 - Internal Server Error
- So Many Rows, So Little Time! - Case Study
- XDO: An XML Engine Class for Classic ASP
- Credit Card Fraud Prevention Using ASP and C...

Watch our Tech Videos 
Dev Articles Forums 
 RSS  Articles
 RSS  Forums
 RSS  All Feeds
Write For Us 
Weekly Newsletter
Developer Updates  
Free Website Content 
Contact Us 
Site Map 
Privacy Policy 

Developer Shed Affiliates


© 2003-2018 by Developer Shed. All rights reserved. DS Cluster - Follow our Sitemap
Popular Web Development Topics
All Web Development Tutorials