Development system with methods for runtime binding of user-defined classes

• US 5,953,524 A
• Filed: 11/22/1996
• Issued: 09/14/1999
• Est. Priority Date: 11/22/1996
• Status: Expired due to Term

• Current Assignee: Sybase Incorporated (SAP SE)
• Original Assignee: Sybase Incorporated (SAP SE)
• Inventors: Meng, Peihuan, Barrington, Steven M.
• Primary Examiner(s): Hafiz, Tariq R.
• Assistant Examiner(s): DAS, CHAMELI
• Application Number:
  US08/755,054
• Time in Patent Office: 1,026 Days
• Field of Search: 395/683, 395/704, 395/135, 395/340, 395/701
• US Class Current: 717/108
• CPC Class Codes: G06F 9/44521 Dynamic linking or loading; Link editing at or after load time, e.g. Java class loading

Abstract

A multimedia application development system including an authoring environment and a runtime module for executing applications developed in the authoring environment is described. The system allows creation of customized objects (e.g., custom controls), by creating a user-defined class or "UDC." Typically, a UDC is created from one or more existing classes, inheriting, at least in part, behavior and functionality of those existing classes. The system provides methods where actual binding of properties and methods to an object instance of a class is deferred until runtime. With specific regard to UDC-created objects, the behaviors of parent classes are not bound to object instances at compile time. Instead, these behaviors are "late bound" by fetching them from the parent classes at runtime, on an "as needed" basis. Further, "which" particular parent classes are actually employed for this purpose at runtime can be altered, thereby providing further flexibility to the system. Since the UDC is bound only at runtime, the specific UDC actually employed can be changed up to the point of actual execution. As a result, the behavior for the object at runtime can be changed dramatically by simply re-directing the object to a different UDC (which may be one of many compatible UDCs). In this manner, the actual "context" of execution of an application at runtime depends on the particular context in which the application finds itself.

Claims

1. In a system for creating and using objects created from classes in a computer, each class providing at least one prototype defining behavior for an object, a method for providing runtime binding of classes to objects upon execution of a program, the method comprising:

specifying creation at runtime of a particular object of a particular class, said particular object being constructed to dynamically accept one of several prototypes from the particular class, in order of a pre-selected preference, during runtime execution of the program; and

at runtime, creating the particular object by performing such steps of;

(i) attempting to read the prototype from the class which is preferred for creation of the particular object,

(ii) if the prototype which is preferred for creation of the particular object cannot be read, attempting to read other prototypes from the class according to the order of the pre-selected preference, until a prototype is successfully read,

(iii) if prototype for the class is found, reading a prototype from a parent class from which the object class inherits, and

(iv) creating the object based on a prototype which has been successfully read, so that the object exhibits runtime behavior defined by the prototype.

2. The method of claim 1, wherein said object comprises a user interface control.

3. The method of claim 1, wherein said particular object displays a graphic image, so that the particular graphic image displayed by the object is determined by which prototype the object has successfully read.

4. The method of claim 1, wherein the particular object is provided with a default prototype for use in the event that no prototypes can be successfully read.

5. The method of claim 4, wherein the prototypes for the class are stored on at least one remote system, except for the default prototype which is stored locally.

6. The method of claim 1, wherein at least one prototype is stored on a remote computer system.

7. The method of claim 6, wherein said at least one prototype stored on a remote computer system is stored on a remote server connected to the Internet.

8. The method of claim 1, wherein behavior defined by a prototype includes properties and methods for an object created from that prototype.

9. The method of claim 8, wherein said methods include at least one event handler for processing events which occur at objects in the system.

10. The method of claim 1, wherein step (i) and (ii) include searching for a prototype on the Internet, on a local area network, and on a local storage device.

11. The method of claim 1, wherein behavior of the particular object can be modified without change to the program, by only changing at least one of the prototypes for the object class.

12. The method of claim 11, wherein said step of changing at least of one the prototypes comprises:

changing a prototype on a computer system other than one in which the program is stored.

13. The method of claim 1, further comprising:

storing with the program at least one copy of all prototypes necessary for initial display of the program at runtime.

14. The method of claim 13, further comprising:

presenting the initial display of the program using prototypes stored with the program and, thereafter, replacing the initial display with one comprising objects created from remote prototypes, as they become available.

15. In a system for creating and using objects created from classes in a computer, each class providing at least one prototype defining behavior for an object, a method for handling events which occur at objects, the method comprising:

(a) receiving notification of an event occurring in the program;

(b) determining a particular object which is associated with the event;

(c) determining whether the particular object has an event handler capable of processing the event;

(d) if an event handler is not found, determining whether other prototypes of the class from which the object is created include an event handler capable of processing the event;

(e) if an event handler is not found, examining a next higher-level object for the event handler capable of processing the event;

(f) if an event handler is not found, repeating step (e) with a next higher-level object until an event handler is found or no higher-level object exists; and

(g) if an event handler is found, invoking the event handler by passing it the event, providing normal processing of the event.

16. The method of claim 15, wherein the event occurs at an object comprising a user interface control.

17. The method of claim 16, wherein an event handler for the event is found at a page object which contains the user interface control.

18. The method of claim 15, wherein each event handler is associated with script instructions defining how the event handler is to process an event.

19. The method of claim 15, wherein said event occurs in response to user input.