Context Toolkit: Tutorial: Helper Classes

This file contains a list of classes that are useful and/or necessary to understand, when dealing with the context toolkit.

Necessary Classes

In this section, I'll briefly describe the classes that are necessary to understand in order to use the context toolkit. Some classes have been described in other files and will not be repeated here - links will be provided to those descriptions.
BaseObject (link)
Widget (link)
Server (link)
Interpreter (link)
DataObject
DataObject is one of the most important classes in the context toolkit. It is used as an intermediate object to pass data between components. Almost any helper class in the context toolkit can be converted to a DataObject (as seen by the toDataObject() methods in many classes) and can be created from a DataObject (as seen by the constructors that take only a DataObject parameter). For outgoing communications, classes are converted to a DataObject (usually automatically). The DataObject is then encoded and a protocol is added, and the data is sent out. By having a single object that we can convert all other objects to, we can more automatically handle the communications between components. It allows us to effectively pass objects between distributed components, without having to use a programming language specific mechansim like Remote Method Invocation or a heavyweight mechanism like CORBA. On the incoming side, once the protocol is stripped, the data is decoded to form a DataObject. In some cases, the DataObject is automatically converted to the object that it was created from (on the output side). However, in most cases, the programmer is left to convert the DataObject.
Error
All of the communications between components return a DataObject to the component initiating the communications. In every case, an Error object can be created from the DataObject. This object describes whether or not the communication request was successful. If successful, the error string will be NO_ERROR. If not successful, the error string will be set to an appropriate error, depending on the reason for the failure. It is suggested that when debugging, you always check the Error object as it is often a useful source of information (when things go wrong).
Attribute (link)
AttributeFunction (link)
AttributeNameValue (link)
Condition (link)
Retrieval (link)
RetrievalResults (link)
Callback (link)
Subscriber (link)
WidgetHandle (link)

Useful Classes

In this section, I'll briefly describe the classes that are useful to understand in order to use the context toolkit.
Constants
Constants is essentially a list of important constants used by the various context components.
ContextTypes
ContextTypes is essentially a list of context types that we have used in our applications so far.
ConfigObject
A ConfigObject is similar to a WidgetHandle. It basically encapsulates the information necessary to communicate with any context components (not just a widget). This information includes the hostname, port, id and type of component.
Configuration
A Configuration object is used to collect information about all the widgets, interpreters, and servers being used in a particular application. Typically this information is stored in a file such as this. This information is put in a DataObject and converted to a Configuration object. It organizes the information in the form of collections of ConfigObjects, organized by widgets, interpreters and servers.
XMLURLReader
The XMLURLReader is used to read a configuration file for a given application that has been written in XML, such as this. It reads in the file and makes the results available as a DataObject, which can then be converted to a Configuration object.
Back to the Table of Contents.

Forward to the Known Bugs and Problems section.

Context Toolkit Home
Last Modified: Feburary 11, 2000
Comments to: anind@cc.gatech.edu