Browse Prior Art Database

Event Notification Mechanism

IP.com Disclosure Number: IPCOM000104475D
Original Publication Date: 1993-Apr-01
Included in the Prior Art Database: 2005-Mar-19
Document File: 4 page(s) / 160K

Publishing Venue

IBM

Related People

Kehn, DB: AUTHOR

Abstract

IBM's Common User Access* (CUA*) '91 architecture defines an advanced object-oriented graphical user interface (GUI). Objects presented by this GUI may have many different concurrent appearances. For example, a calendar object, as shown in Fig. 1, may be viewed as a list of reminders for the day, week, or year. It may be shown graphically in many ways, but each view is a visual representation of the same underlying object, calendar.

This text was extracted from an ASCII text file.
This is the abbreviated version, containing approximately 43% of the total text.

Event Notification Mechanism

      IBM's Common User Access* (CUA*) '91 architecture defines an
advanced object-oriented graphical user interface (GUI).  Objects
presented by this GUI may have many different concurrent appearances.
For example, a calendar object, as shown in Fig. 1, may be viewed as
a list of reminders for the day, week, or year.  It may be shown
graphically in many ways, but each view is a visual representation of
the same underlying object, calendar.

      The different views of a calendar may be requested by the user
at the same time.  A change to calendar made by one view is reflected
in all other views of calendar.  For example, if an appointment was
added to calendar in the Daily Reminder view, it should be reflected
in the other two views, Hourly Reminder and Week-at-a-Glance, if
appropriate.

      The type of GUI described above allows for multiple views on a
single object.  Each view on the object can modify the data of the
underlying object, potentially affecting the appearance of other
views of that same object.  The view(s) on a given object must know
when the state of the object changes.  Traditionally, the view(s) are
notified with a message where the only parameter is the changed
object.  The receiver then interrogates the changed object to
determine the nature of the change.  This simplistic approach is
workable, but results in repetitive code.

      The description above shows the need for views to be notified
of the occurrence of an event.  This notification mechanism is the
novelty here.  Notification mechanisms have existed before; this
mechanism differs in that it is more flexible and more extensible.

      Prior notification mechanisms consisted of a list of interested
parties (e.g., three calendar views, as shown in Fig. 1) typically
maintained by the object of interest (e.g., calendar).  When an event
of interest occurred, the object of interest would send a message to
each of the interested parties in the list.  In one object-oriented
language commonly used, the notification message is determined by the
interested party, but the parameter is always, by convention, the
object of interest.   For example, the interested party might choose
to receive a calendarChanged: aCalendar message, where aCalendar is
the object shown in Fig. 1.  The interested party is responsible for
interrogating the object of interest to determine the nature of the
change.

      The new notification mechanism was created by recognizing that
the information needed by the target can be categorized.  This
eliminates most, if not all, of the need to interrogate the object of
interest.  The interested party can select its own notification
parameter(s) whose values can be obtained from different sources
(object of interest, or another object).

      The notification mechanism is characterized by the design of
the protocols used by the objects participating in an event
notification:

o...