| In this article, I describe pseudo-objects and illustrate how to program with them. |
Tools & Resources
The following tools and resources are recommended for testing the example programs that are presented in this article:
Note: Having access to a database is not absolutely necessary. With just a little work, the sample programs that I present can be modified so that they don't access a database.
Many ASP programs are written in VBScript, which does not provide a way to create user-defined objects (unlike VB). That is, in VBScript you can't define your own classes then create objects from those classes.
However, ASP has an object called Dictionary that is similar to an Associative array in Perl or a Hashtable in Java. It provides a mechanism by which you can store key-value pairs. Here ["DictionaryObj.asp"] is a simple program that demonstrates using the Dictionary object. It creates a Dictionary object, adds some items to it, then displays the contents of the object.
With the Dictionary object you can create "objects" with dynamically defined fields. They are not real objects, because they don't have methods, but are useful nonetheless. Thus, I call them "pseudo-objects". A simple example program that illustrates a basic pseudo-object called "Car" is here ["BasicObj.asp"]. It creates a new Car pseudo-object, sets the fields, then displays the object.
Even though methods cannot be defined for pseudo-objects, functions and subroutines can be written that manipulate pseudo-objects in a similar manner. For example, the Car_New() function in "BasicObj.asp" creates and returns a New Car object.
The functions and subroutines for a pseudo-object can be packaged together in an include file to create an encapsulated unit that is similar a complete user-defined object. You will see an example of this in the next section.
Database objects provide a layer of separation between the application and the database, because programs only have to deal with the objects, not the database. One way to implement database pseudo-objects is to write functions and subroutines that retrieve, create, update, and delete objects that are stored in a database.
A program that illustrates a database version of the Car pseudo-object shown in the previous section is here ["DatabaseObj.asp"]. It creates a few Car pseudo-objects in the database, loads a list of the cars that match given criteria, shows the list, sets the color of each car in the list to blue, shows the list again, deletes one car, loads a list of all cars, then shows the list one final time.
Note that the "DatabaseObj.asp" program assumes the following:
After using pseudo-objects a couple of times, I realized that I had redundant code in each object that could be abstracted. So, I created a generic pseudo-object, which I called an Entity. Then, I implemented other pseudo-objects in my applications as compositions of the Entity pseudo-object. Essentially, this is one way to achieve the equivalent of inheritance in a programming language that is not object-oriented. (You can do something similar in VB to fake inheritance.)
The code for the Entity pseudo-object is here ["Entity.inc"].
An implementation of the Car pseudo-object that has been re-written as a composition of the Entity pseudo-object is here ["Car2.inc."].
Notice that each function or subroutine is merely a wrapper for the corresponding function or subroutine of the Entity pseudo-object. If you modify "DatabaseObj.asp" so that it includes "Entity.inc" and "Car2.inc" instead of "Car.inc", it should run correctly without any other changes. (Note: Be sure "Entity.inc" is included before "Car2.inc".)
Since pseudo-objects are based on the ASP Dictionary object, inspection of the fields is possible. First, the field names are just the keys in the Dictionary and can be retrieved with the Keys() method. Second, the field types can be determined with the TypeName() function. Here ["FieldInspection.asp"] is a simple example.
With field inspection, more advanced operations are possible, such as serialization and simple cloning. These are presented in the next two sections.
As I used pseudo-objects for more applications, I discovered that I needed to pass them from one program to another, or create them from an input form. So, I implemented a couple of routines to serialize and deserialize pseudo-objects. The code for them can be seen in "Entity.inc".
Basically, Entity_URLEncode() serializes an object to a string that is URL encoded, so that it can be passed as a series of URL parameters. Entity_URLDecode() reverses the process, decoding data from a given Request object (an ASP object that contains HTTP request data) into an empty pseudo-object. The fields of the pseudo-object are determined by using field inspection to examine the empty pseudo-object.
A program that illustrates serialization and deserialization of a pseudo-object is here ["SerialObj.asp."]. It creates a pseudo-object, presents a form for changing the fields. When the user clicks the "Submit" button, the Car object will be updated and show in the form again. When the user clicks on the "Revert" link, any changes will be discarded and the previous car object will be displayed in the form.
At some point in development of an application, I determined that I needed to make a copy of a pseudo-object. So, I wrote Entity_Clone(), a function that returns a copy of a given object. Note, though, that Entity_Clone() only makes a shallow copy. If the given object contains references to other objects, those objects will not be cloned.
Entity_Clone() uses field inspection to examine the given object and Determine its field names, then uses the field names to copy the field values to a new object. You can see the code for it in "Entity.inc". Also, here ["CloneObj.asp"] is a simple program that creates a pseudo-object, clones it, then displays both objects.
In this article, I have described pseudo-objects, illustrated how to use them, and shown some advanced operations that can be performed with them. Hopefully, you have seen how they can provide a good layer of separation between ASP programs and a database.
About the author:Thornton Rose is a software developer who lives and works in Atlanta, Georgia. He can be reached via e-mail at email@example.com.