Contents of this Section:
Overview of Tasks and Events
Overview of Tasks and EventsObject-Oriented Concepts and Terms
Packages and Classes
Methods
Events and Tasklists
For a short, readable introduction to object-oriented terminology and concepts, you might consider Object-Oriented Technology: A Manager's Guide, by David A. Taylor, Ph.D., Addison Wesley, 1990.
Also, if you have a set of Progress Software manuals, look at chapter 2 ("Programming Models") in the Programming Handbook for a reasonably good discussion of the differences between traditional procedure-driven programming and new event-driven programming models. When reading this chapter, which is oriented specifically to the Progress language, think of Progress "trigger procedures" as similar to "tasklists" in Jargon Writer, since the analogy is very close.
Some related Web sites of interest include:
Object-Oriented Concepts
and Terms
Jargon Writer and Jargon Reader are written in the JavaTM programming language, which is a pure object-oriented language, unlike C, Visual Basic, the Progress 4GL, and most other programming languages. Jargon ReaderX is written in C++ specifically for the Windows platform, using only the object-oriented features in C++ and not the "C"-like features.
The XML application objects which are created by Jargon Writer and executed by Jargon Reader are "aggregate" objects consisting of a set of high-level component instruction objects and business task objects. All tasks executed on the client in response to events, and all responses from host systems, are also sets of similar objects. Thus, both products implement pure object-oriented applications on the client, and also use object-like shell procedures for host applications. Whether the business logic that you include in these procedures is object-like or not is up to you, since many host procedure languages (unlike Java) allow both procedural and object-like programming paradigms.
The following discussion of terminology draws heavily on the definitions in Dr. Taylor's book (cited above). While there are still a number of alternative ways of naming these concepts, some growing out of different languages (C++ vs. Smalltalk), or out of the books of different "experts", Dr. Taylor's terminology is widely understood and accepted.
An object is a software "bundle" that combines a set of related data elements, called variables, with the procedures that can operate on these variables, called methods. An object is an instance of a class, which defines the contents of the object. You can think of a class as a template or cookie cutter. Each time a new object is needed, a new instance of the class is instantiated, or "stamped out" with the cookie cutter. The class contains the data and method definitions, so they do not have to be repeated in every object that is an instance of the class. The objects themselves only need to contain the actual values of the variables.
For example, consider a class called "customer". The definition of this class would contain the variables for all the information we want to know about our customers, such as customer ID, name, address, etc. The class definition would also contain the methods needed to create a new customer object, to read (get) the values of a particular customer, to assign (set) values to a customer, to calculate a customer's aged balances, and similar methods.
Each instance of the class will be a specific customer object, one for customer "A", another for customer "B", and so on. You can think of objects as being similar to records in a database table (or "rows in a table" for purists) as far as the data side is concerned. The big difference is that objects encapsulate all the programming logic that can work with an object's data into the object itself in their methods. Generally speaking, only an object itself can change its own data. Encapsulation provides several benefits to developers. It protects data from accidental corruption by other objects and hides low-level details from other parts of an application.
Classes are usually defined in a class hierarchy (or inheritance tree), with the top level being a very general class (like "screen object"), and lower levels in the hierarchy being more specialized versions of the general class. For example, the general class "customer" may have as subclasses "retail customer" and "dealer", and "dealer" may have "convenience store" and "super-store" subclasses. Subclasses can be nested to any level.
Through another object-oriented concept called inheritance, all the subclasses of a given superclass ("parent" class) can use the methods and variables of that parent class. Likewise, any subclasses of a subclass can also do so, recursively. This means that a subclass only needs to define those variables and methods that are specialized for it, without repeating all the variables and methods that are identical to those in its parent classes (all classes above a subclass in the hierarchy). This feature considerably reduces redundant coding and streamlines designs.
Besides inheritance and encapsulation, a third essential feature of an object-oriented language is polymorphism. This term, whose linguistic roots roughly translate as "many shapes", refers to the ability to have multiple classes that define a method that has the same name but is implemented differently in each class. For example, every class might have a method called "print", but a "text editor" class might implement it quite differently than would a "3D color photo" class. What is beneficial about this feature is that any object can invoke the "print" method on any other object, including new objects that might be added in the future, without having to know anything else about how the "print" method is implemented. This drastically reduces maintenance requirements when a system undergoes changes and enhancements.
Objects can only directly change their own variables, not those of other objects. Thus, for one object to affect the contents of another object, the first object must ask the second object to perform the desired action on its own contents. This is done by passing messages between objects. The interface definition of a message contains the name of the receiving object, a method name of that object, and zero or more parameters required by a method's signature. In Java, methods are defined with zero or more parameters, and all references to a method must include the correct number of parameters, of the correct data types, in the correct order. A Java method always sends back exactly one return value to the invoking object, which may be nothing (void), a simple data value such as an integer or a boolean (true/false) value, or an object of a specified type (actually a reference or "handle" to an object, not a copy of the object's values).
Two objects may interact by message passing whether they are running
in the same Java Virtual Machine (JVM) on one computer, in two JVMs on
the same computer, on two different computers on the same internal network,
or on two computers at different locations that are connected via the Internet.
When objects on different computers are able to interact with each other,
they are referred to as
distributed objects.
The standard Java Development Kit (JDK) provided by Sun Microsystems includes a comprehensive set of classes used to develop Java programs. This set of classes is called the Java Application Programming Interface (API). These classes are organized into several groups of related classes called packages.
Of particular interest in Jargon Writer are two packages that are used to develop a graphical user interface (GUI). These are the Abstract Windowing Toolkit (AWT) package, and the Swing package that is part of the Java Foundation Classes (JFC). The Swing classes are primarily subclasses of AWT classes, and generally offer greater functionality and flexibility than their corresponding AWT superclasses.
Jargon Software has developed several packages of additional classes
which interact with these standard Java classes. Some of these classes
act as component factories by invoking methods of the AWT and Swing
classes to produce and act upon GUI objects in a client application. Other
classes define the high-level processing specifications contained in the
application objects created by Jargon Writer. These high-level classes
send "orders" to the "factories", which use the AWT and Swing classes as
tools to create graphical objects such as panels, buttons, text fields
and similar components. The high-level classes can also modify the state
of these objects, such as by making them visible, enabled, disabled or
by assigning or reading their values.
When you are adding client and host tasks to an application in Jargon
Writer, you can use many of the public methods of the classes in
the AWT, Swing and Jargon Software packages. There are also a number
of utility methods which can be used for actions that do not directly
act upon a specific object, but rather pertain to the application as a
whole (at the "root" level). These methods and the objects on which
they act are defined as part of a client or host task in the Task
Properties Panel of the Task Editor Window.
Technical Note: Public methods can be invoked by any other object, whereas private methods can only be invoked by other methods within the same object and are not "visible" to other objects. Protected methods can only be invoked by the object itself or by objects in subclasses of an object's class.
A host can also invoke an existing client tasklist that contains
one or more tasks that invoke such methods, which can be a more efficient
way to do the same thing, rather than invoking each method separately from
the host.
Finally, any client method (except those which use other objects as parameters) can also be directly specified by a host procedure by sending an "invoke" message to the client. This powerful, generic capability allows host procedures full ability to dynamically create and modify the state of client components and tasks.
The methods available for use in client and host tasks are shown in alphabetical order in a listbox in the Task Properties Panel for the class which is highlighted in the top listbox in the same panel. Classes are listed in hierarchical order, with the most general superclass at the top of the list, and the most specific subclass (usually a Jargon Software class) at the bottom.
Each method is documented in online HTML-based help files which can
be viewed in a browser. These are grouped by package into separate API
document sets, with each package having a package index, a method index,
a class hierarchy diagram, and individual class descriptions which include
variable and method definitions, comments and examples. These help files
can be accessed by clicking the "Help" button in the Task Properties Panel
for the highlighted method, or from links on the Index
to Online Help Documents.
When are methods actually executed or run? When an application developed in Jargon Writer is first opened and loaded by Jargon Reader, the methods referenced by the component instruction objects are executed. This initialization process instantiates the various graphical objects defined in the application, sets the initial state of each object, stores all defined tasklists, tasks and event linkages, and instantiates event-handling objects which listen for any linked events .
An application may also define an "initial tasklist" which is executed immediately after the initialization. For example, an initial tasklist might contain a host task which causes certain comboboxes and listboxes to be dynamically populated with values from database table contents.
Then, the application simply "sits and waits" until the user performs some action with the keyboard or mouse, which causes an event to take place. If that event is linked with one or more tasklists (which Jargon Writer implements by registering event listener objects to watch for specified events on such an event source object), the tasks in the linked tasklists will be executed when the event occurs. These tasks may be client (local) tasks, host (remote) tasks, or any combination of the two. After all of the linked tasks have been completed for an event, the application returns to the "sit and wait" mode until another event occurs.
What kind of events can occur? The AWT handles two different types of events: low-level and semantic. Low-level events correspond to specific physical actions of the mouse or keyboard, such as a mouse click or a key being pressed. However, the meaning of these low-level events varies, depending on what kind of object is involved.User Tip: This model, where user actions control the logic flow of the program, is called the "event-driven" programming model. Learning to think about programming in this way requires a mental paradigm shift which can sometimes be difficult for developers who have only used the traditional procedural model, where the program "leads" the user through a controlled sequence of actions and limits the choices available to the user at each step. Likewise, learning to think naturally in terms of "objects" instead of "data and programs" can be challenging. Don't worry. The light bulb will come on, that wonderful "ah-ha!" sensation will occur as all the pieces come together, and soon you will wonder why anyone would ever develop software any other way!
For example, clicking a "Save" button usually causes a program to save the current values of its data contents, but clicking on a text field merely puts keyboard focus on the field (focus means that any keystrokes will be applied to that field on the screen). A user changes focus by clicking on a different object, or by using the Tab and Shift-Tab keys to move from the object which currently has focus to the next or previous object in the component traversal sequence (usually left to right and top to bottom).
For this reason, semantic events are normally more useful, since they correspond to the meaning of a mouse or keyboard action. For example, a user can cause the semantic event called "Action Event" for certain components either by clicking the mouse or by pressing the Enter key (both have the same meaning and will cause the same linked tasks to be executed) . The events that can be linked to tasklists in Jargon Writer are primarily semantic events. Whenever possible, semantic events should be used instead of low-level events, since this approach could automatically handle new input methods that cause the same semantic actions. In the future, a user might be able to trigger an Action Event by saying "Make it so!" (while imitating Patrick Stewart, of course).
The kinds of semantic events that can be linked to tasklists in Jargon Writer include: