CA2365572C - Extending the attributes of an application generated using a fourth generation programming tool - Google Patents
Extending the attributes of an application generated using a fourth generation programming tool Download PDFInfo
- Publication number
- CA2365572C CA2365572C CA002365572A CA2365572A CA2365572C CA 2365572 C CA2365572 C CA 2365572C CA 002365572 A CA002365572 A CA 002365572A CA 2365572 A CA2365572 A CA 2365572A CA 2365572 C CA2365572 C CA 2365572C
- Authority
- CA
- Canada
- Prior art keywords
- component
- application
- implementation
- programming tool
- application code
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Expired - Lifetime
Links
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F9/00—Arrangements for program control, e.g. control units
- G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
- G06F9/44—Arrangements for executing specific programs
- G06F9/448—Execution paradigms, e.g. implementations of programming paradigms
- G06F9/4488—Object-oriented
- G06F9/4492—Inheritance
Abstract
A method and apparatus are provided for extending the behavior and attributes of applications designed using a fourth generation language (4GL) programming tool. Specifically, a 4GL programming tool is provided that allows application designers to specify the implementation classes of the components that are used in the applications that they design using the 4GL programming tool.
The implementation classes thus specified may define attributes and behaviors not supported by the corresponding component implementations provided with the 4GL programming tool. During runtime, methods in the specified implementation classes are invoked. To correctly invoke the methods of user-specified implementation classes, the interfaces of the methods must be known to the entity performing the invocations. Therefore, according to one aspect of the invention, all component implementations that are to be used by the application, including both the "standard" component implementations provided with the 4GL
programming tool and the "custom" component implementations specified by the application designer, implement a common interface.
The implementation classes thus specified may define attributes and behaviors not supported by the corresponding component implementations provided with the 4GL programming tool. During runtime, methods in the specified implementation classes are invoked. To correctly invoke the methods of user-specified implementation classes, the interfaces of the methods must be known to the entity performing the invocations. Therefore, according to one aspect of the invention, all component implementations that are to be used by the application, including both the "standard" component implementations provided with the 4GL
programming tool and the "custom" component implementations specified by the application designer, implement a common interface.
Description
EXTENDING THE ATTRIBUTES OF AN APPLICATION GENERATED USING
A FOURTH GENERATION PROGRAMMING TOOL
FIELD OF THE INVENTION
The present invention relates to computer systems and, more specifically, to extending the attributes of an application generated using a fourth generation programming tool.
BACKGROUND OF THE INVENTION
While computers themselves have automated many tasks that had previously been performed manually, it has only been fairly recently that the task of programming the computer has achieved some level of automation. Early computer programming languages required the programmer to manually enter all of the code of an application, usually by typing source code in a text file. While such manual code entry was tedious and error prone, it did have the advantage that virtually all aspects of the resulting applications were entirely under the control of the programmer.
Programmers could modify their programs however they saw fit by simply modifying the underlying code.
Over time, techniques have been developed to automate the creation of applications. In particular, tools have been developed to allow users to design applications, and to automatically generate code that implements those applications, simply by interacting with user interface controls. Such tools are generally referred to as fourth generation (4GL) programming tools.
For example, a 4GL programming tool may present an application designer with a window that represents the interface that the to-be-generated application will display to its users. The 4GL programming tool may further present the application designer with user interface design tools that allow the application designer to visually "paint" standard user interface components onto the window. For example, the user interface design tools may allow the application designer to place check boxes, menus, dialog boxes, list boxes, and buttons onto the window, and allow the application designer to specify what should happen when the user interacts with those components.
The user may view a "property palette" for each user interface component that the user has placed on the window. The property palette lists the properties of the user interface component that can be specified by the user, and the current value of those properties. For example, a property for a button component may be "label", where the value assigned to the label property is the text that is displayed on the button.
Once the application designer has finished designing the application, the 4GL
programming tool automatically generates code for the application. The form of the code thus generated may vary from implementation to implementation. For example, the 4GL programnung tool may generate machine-executable code, source code, and/or metadata. For the purpose of explanation, the term "application code"
shall be used herein to refer to the data generated by a 4GL programming tool to specify the applications designed using the 4GL programming tool, regardless of the form of that data.
Frequently, the 4GL programming tool is used to generate application code that is not directly executable by a computer, but which, when executed by a particular runtime engine, implements the application that was designed using the 4GL programming tool. For example, the runtime engine reads the application code generated by the 4GL programming tool, and "executes" the application code by displaying the window previously designed by the application designer, along with all of the user interface components that were added to the window by the application designer. When the user interacts with those user interface components, the application performs the actions that the application programmer assigned to those components using the 4GL programming tool.
4GL programming tools make designing applications far easier and faster, and less error prone, than manual coding techniques. However, the ease and speed gained by 4GL programming is not without its price. In particular, the virtually unrestrained flexibility and control provided by manual coding is lost.
Instead, the 4GL programming tool user is typically presented with a "canned" set of standard user-interface components. The code that actually implements those components is typically contained in a compiled library that is distributed with the 4GL
programming tool, and are thus generally inaccessible to the user.
Consequently, the user is limited to (1) the set of components offered by the 4GL programming tool, (2) the properties provided by those components, and (3) the functions performed by the methods provided for those components. Even slight deviations from the norm, such as presenting an oval button instead of a rectangular button, are not possible if the components provided by the 4GL programming tool do not have user-settable properties that allow the deviations. For example, for a 4GL programmer to use oval buttons, the button component provided by the 4GL programming tool would have to provide a "shape" property that may be changed from "rectangle" to "oval". If the .
button component does not have a "shape" property, or if "oval" is not a value supported for the shape property, then the user cannot design applications that have oval buttons.
The attributes and behaviors of the user interface (UI) and software components that a 4GL programmer may incorporate in an application are implemented in object classes supplied in a library that is provided with the programming tool. The library is typically supplied in compiled form, so that it is not editable. When the user designs an application that uses a button, for example, the 4GL programming tool generates code which, when executed by the runtime engine, results in calls being made to methods within the "button" class in the library provided with the 4GL programming tool. If the "display" method of the button class is designed to display a rectangular button, then a rectangular button will be displayed, even if the designer would prefer an oval button.
Based on the foregoing, it is clearly desirable to provide a method and system that allows applications to be designed easily and quickly using 4GL
programming tools, but which allows greater flexibility than current 4GL programming tools. In particular, it is desirable to provide a 4GL programming tool that does not restrict users to only those implementations of components that are supplied with the programming tool.
SUMMARY OF THE INVENTION
According to one aspect of the invention, a 4GL programming tool is provided that allows application designers to specify the implementation classes of the components that are used in the applications that they design using the programming tool. The implementation classes thus specified may define attributes and behaviors not supported by the corresponding component implementations 13-07-2001 , . US0014624 provided with the 4GL programming tool. During runtime, methods in the specified implementation classes are invoked. To correctly invoke the methods of user-specified implementation classes, the interfaces of the methods must be known to the entity performing the invocations. Preferably, therefore, all component implementations that are to be used by the application, including both the "standard"
component implementations provided with the 4GL programming tool and the "custom" component implementations specified by the application designer, implement a common interface.
BRIEF DESCRIPTION OF THE DRAWINGS
The present invention is illustrated by way of example, and not by way of limitation, in the figures of the accompanying drawings and in which like reference numerals refer to similar elements and in which:
FIG. 1 is a block diagram of a 4GL application development system that supports the use of user-specified component implementations according to an embodiment of the invention; and FIG. 2 is a block diagram illustrating a computer system upon which . - ~ .
embodiments of the present invention may be implemented.
DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENT
A method and apparatus are described for extending the attributes of an application generated using a 4GL programming tool. In the following description, for the purposes of explanation, numerous specific details are set forth in order to provide a thorough understanding of the present invention. It will be apparent, however, to one skilled in the art that the present invention may be practiced without these specific details. In other instances, well-known structures and devices are shown in block diagram form in order to avoid unnecessarily obscuring the present invention.
FUNCTIONAL OVERVIEW
A 4GL programming tool is provided that, similar to conventional 4GL
programming tools, allows users to design applications without manually typing the code for the applications. According to one embodiment, users use the 4GL
A FOURTH GENERATION PROGRAMMING TOOL
FIELD OF THE INVENTION
The present invention relates to computer systems and, more specifically, to extending the attributes of an application generated using a fourth generation programming tool.
BACKGROUND OF THE INVENTION
While computers themselves have automated many tasks that had previously been performed manually, it has only been fairly recently that the task of programming the computer has achieved some level of automation. Early computer programming languages required the programmer to manually enter all of the code of an application, usually by typing source code in a text file. While such manual code entry was tedious and error prone, it did have the advantage that virtually all aspects of the resulting applications were entirely under the control of the programmer.
Programmers could modify their programs however they saw fit by simply modifying the underlying code.
Over time, techniques have been developed to automate the creation of applications. In particular, tools have been developed to allow users to design applications, and to automatically generate code that implements those applications, simply by interacting with user interface controls. Such tools are generally referred to as fourth generation (4GL) programming tools.
For example, a 4GL programming tool may present an application designer with a window that represents the interface that the to-be-generated application will display to its users. The 4GL programming tool may further present the application designer with user interface design tools that allow the application designer to visually "paint" standard user interface components onto the window. For example, the user interface design tools may allow the application designer to place check boxes, menus, dialog boxes, list boxes, and buttons onto the window, and allow the application designer to specify what should happen when the user interacts with those components.
The user may view a "property palette" for each user interface component that the user has placed on the window. The property palette lists the properties of the user interface component that can be specified by the user, and the current value of those properties. For example, a property for a button component may be "label", where the value assigned to the label property is the text that is displayed on the button.
Once the application designer has finished designing the application, the 4GL
programming tool automatically generates code for the application. The form of the code thus generated may vary from implementation to implementation. For example, the 4GL programnung tool may generate machine-executable code, source code, and/or metadata. For the purpose of explanation, the term "application code"
shall be used herein to refer to the data generated by a 4GL programming tool to specify the applications designed using the 4GL programming tool, regardless of the form of that data.
Frequently, the 4GL programming tool is used to generate application code that is not directly executable by a computer, but which, when executed by a particular runtime engine, implements the application that was designed using the 4GL programming tool. For example, the runtime engine reads the application code generated by the 4GL programming tool, and "executes" the application code by displaying the window previously designed by the application designer, along with all of the user interface components that were added to the window by the application designer. When the user interacts with those user interface components, the application performs the actions that the application programmer assigned to those components using the 4GL programming tool.
4GL programming tools make designing applications far easier and faster, and less error prone, than manual coding techniques. However, the ease and speed gained by 4GL programming is not without its price. In particular, the virtually unrestrained flexibility and control provided by manual coding is lost.
Instead, the 4GL programming tool user is typically presented with a "canned" set of standard user-interface components. The code that actually implements those components is typically contained in a compiled library that is distributed with the 4GL
programming tool, and are thus generally inaccessible to the user.
Consequently, the user is limited to (1) the set of components offered by the 4GL programming tool, (2) the properties provided by those components, and (3) the functions performed by the methods provided for those components. Even slight deviations from the norm, such as presenting an oval button instead of a rectangular button, are not possible if the components provided by the 4GL programming tool do not have user-settable properties that allow the deviations. For example, for a 4GL programmer to use oval buttons, the button component provided by the 4GL programming tool would have to provide a "shape" property that may be changed from "rectangle" to "oval". If the .
button component does not have a "shape" property, or if "oval" is not a value supported for the shape property, then the user cannot design applications that have oval buttons.
The attributes and behaviors of the user interface (UI) and software components that a 4GL programmer may incorporate in an application are implemented in object classes supplied in a library that is provided with the programming tool. The library is typically supplied in compiled form, so that it is not editable. When the user designs an application that uses a button, for example, the 4GL programming tool generates code which, when executed by the runtime engine, results in calls being made to methods within the "button" class in the library provided with the 4GL programming tool. If the "display" method of the button class is designed to display a rectangular button, then a rectangular button will be displayed, even if the designer would prefer an oval button.
Based on the foregoing, it is clearly desirable to provide a method and system that allows applications to be designed easily and quickly using 4GL
programming tools, but which allows greater flexibility than current 4GL programming tools. In particular, it is desirable to provide a 4GL programming tool that does not restrict users to only those implementations of components that are supplied with the programming tool.
SUMMARY OF THE INVENTION
According to one aspect of the invention, a 4GL programming tool is provided that allows application designers to specify the implementation classes of the components that are used in the applications that they design using the programming tool. The implementation classes thus specified may define attributes and behaviors not supported by the corresponding component implementations 13-07-2001 , . US0014624 provided with the 4GL programming tool. During runtime, methods in the specified implementation classes are invoked. To correctly invoke the methods of user-specified implementation classes, the interfaces of the methods must be known to the entity performing the invocations. Preferably, therefore, all component implementations that are to be used by the application, including both the "standard"
component implementations provided with the 4GL programming tool and the "custom" component implementations specified by the application designer, implement a common interface.
BRIEF DESCRIPTION OF THE DRAWINGS
The present invention is illustrated by way of example, and not by way of limitation, in the figures of the accompanying drawings and in which like reference numerals refer to similar elements and in which:
FIG. 1 is a block diagram of a 4GL application development system that supports the use of user-specified component implementations according to an embodiment of the invention; and FIG. 2 is a block diagram illustrating a computer system upon which . - ~ .
embodiments of the present invention may be implemented.
DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENT
A method and apparatus are described for extending the attributes of an application generated using a 4GL programming tool. In the following description, for the purposes of explanation, numerous specific details are set forth in order to provide a thorough understanding of the present invention. It will be apparent, however, to one skilled in the art that the present invention may be practiced without these specific details. In other instances, well-known structures and devices are shown in block diagram form in order to avoid unnecessarily obscuring the present invention.
FUNCTIONAL OVERVIEW
A 4GL programming tool is provided that, similar to conventional 4GL
programming tools, allows users to design applications without manually typing the code for the applications. According to one embodiment, users use the 4GL
AMENDED SHEET
programming tool to design applications visually by selecting user interface components, placing the selected user interface components into a window, and specifying property values for those components. However, unlike conventional 4GL programming tools, one component property that is controlled by the S application designer is the implementation class of the component. The value to which the application designer sets the implementation class properly of a component dictates the object class that defines the properties and methods that will be executed at runtime to implement the component. The specified implementation class far a button may be, for example, the standard button class provided by the 4GL programming tool, or a custom designed oval button class written by the application designer or by a third party component developer.
During runtime, methods in the specified implementation class are invoked to instantiate the component and to set and read properties of the component. To correctly invoke those methods, the interfaces of the methods must be known to the entity performing the invocations. Therefore, according to one aspect of the invention, each of component implementations that are to be used by the application, including both the "standard" component implementations in the library provided with the 4GL programming tool and the "custom" component implementations specified by the application designer, implements a common interface.
Figure 1 illustrates a 4GL system 100 according to an embodiment of the invention. The 4GL system 100 includes a 4GL programming tool 112 that an application designer 110 uses to generate application code I 14 that defines an application program. As mentioned above, the application code I 14 may be in a form that is directly executable by a machine, may be in a form that is executable by a virtual machine, or may simply be metadata that describes the application.
In the illustrated embodiment, the application code 114 is in a form that is used by a runtime engine 116 to implement the invention.
At run-time, the application code 114 is "executed" by a runtime engine 116.
Depending on the nature of the application code 114, the process of executing the application code I 14 may, for example, involve interpreting instructions contained in the application code 114 or calling routines that implement application components that are described in the application code 114.
In the illustrated system 100, the applicarion is implemented in a client/server model, where portions of the application run on a server, and other portions of the application run on a client. Typically, the server-side components are on a different machine than the client-side components, and communication between the two sets of components is performed over a network connection.
The server-side components of the application include the application code 114 and the runtime engine 116. The client-side components of the application include components that implement the user interface of the application that is displayed to an application user 124. Those components include a dispatcher 140, message handlers, and views. The illustrated embodiment is shown with three message handlers 128, 130 and 132 and three views 134, 136 and 138.
Each component of the application's user interface has a corresponding view and message handler. For example, assume that the user interface of the application includes a button B 1 and two checkboxes CB 1 and CB2. View 134 and message handler 128 may correspond to the button B1, view 136 and message handler 130 may correspond to the first check box CB1, and view 138 and handler 132 may correspond to the second check box CB2.
A view is an instance of the implementation class of a component. Thus, the view that corresponds to a component includes the code that implements the component. For example, view 134 is an instance of the implementation class that implements button B1. Similarly, views 136 and 138 are instances of the implementation classes that implement check boxes CB l and CB2, respectively.
The views 136 and 138 for check boxes CB1 and CB2 will not contain the same code if, for example, CB 1 is implemented using the default check box implementation class, while CB2 is implemented using a user-specified check box implementation class.
Under those conditions, the code implementing CB 1 would typically be contained in a runtime library distributed with 4GL programming tool 112, while the code implementing CB2 would be implemented in a separate file.
Each type of component has a corresponding type of message handler. The message handler type for a given component type is designed to handle the type of messages associated with that component type. For example, a button message WO 00/72140 PC'T/US00114624 handler listens for and handles the type of messages buttons receive, while a check box message handler listens for and handles the type of messages check boxes receive.
The message handler that corresponds to a component sends messages S relating to events involving the component back to the runtime engine 116.
For example, message handler 128 may detect that the user has clicked on button B
1. In response to detecting the click, the message handler 128 sends a message through dispatcher 140 to runtime engine I 16, making the runtime engine 116 aware that button B 1 has been clicked.
The message handler that corresponds to a component also invokes methods provided by the component's view in response to messages from the runtime engine 116. For example, message handler 128 may respond to a message from runtime engine 116 by calling a method provided by view 134 that changes the color of button B 1.
OPERATION OF RUN-TIME ENVIRONMENT
At runtime, the runtime engine 116 reads and executes the application code 114 that was previously generated by the 4GL programming tool 112. That application code 114 includes data that identifies the implementation class of the application components for which the application designer I 10 specified an implementation class. For example, assume that the default implementation class for buttons is DefButton.class. During application design, the application designer 110 may have specified a different implementation class for the B 1 button that is to be displayed on the user interface of the application. For the purpose of explanation, it shall be assumed that the application designer 110 specified the implementation class of button B 1 to be MyButton.class. Under these conditions, the application code 114 includes data that indicates that the implementation class of B 1 is MyButton.class.
During execution of the application code 114, the runtime engine I 16 sends messages to the dispatcher 140 to cause the creation of the components specified in the application code I 14. For at least those components that do not use the default class implementations, the messages sent by runtime engine 116 include information that identifies the implementation class. For example, it shall be assumed that runtime engine 116 sends a message to dispatcher 140 that requests the creation of button B1 using implementation class MyButton.class.
When dispatcher 140 receives a message from runtime engine 116, dispatcher 140 forwards the message to the message handler that corresponds to the component identified in the message. If a message handler has not yet been initiated for the component identified in the message, then the dispatcher 140 instanHates a message handler of the appropriate component type for the component. For example, if the message received by dispatcher 140 calls for the creation of a button (e.g.
button B 1 ), and a message handler for that particular button has not been instantiated, then I O dispatcher 140 instantiates a button-type message handler (e.g. message handler 128) for the button. After instantiating the appropriate message handler, the dispatcher 140 sends the message to message handler.
When a message handler receives a message to create a component, the message handler determines, based on information contained in the message, 1 S whether the component is implemented using the default class implementation. If the component is implemented using the default class implementation, then the message handler calls the method that instantiates components (i.e. the "constructor") provided by the default class implementation for that type of component. This is typically performed by calling a method in the runtime library 20 provided with 4GL programming tool 112. If the component is implemented using a user-specified class implementation, then the message handler calls the constructor provided by the user-specified class implementation.
For example, in response to a message requesting the instantiation of button B 1, message handler 128 determines that button B 1 is implemented using the user 25 specified implementation class MyButton.class. Message handler 128 would therefore call the constructor provided by the MyButton.class implementation class to instantiate button B 1. Instantiating button B 1 creates an instance of the class MyButton, which is depicted as view 134.
Once a client-side component has been instantiated, the properties of the 30 component must be set to the values specified for the component by the application designer 110. The values for the properties of the component are reflected in the application code 114 generated by the 4GL programming tool 112. After causing the component to be instantiated, the runtime engine 116 sends messages to dispatcher -g_ 140 that indicate the values of the properties of the component. Dispatcher forwards those messages to the message handler that corresponds to the component, and the message handler invokes the appropriate method of the component's view to set the specified property to the specified value.
For example, assume that application designer 110 assigned the value "OK"
to the "Label" property of button B 1. Under these conditions, the application code 114 generated by 4GL programming tool 112 would indicate that the Label property of button B 1 has been assigned the value "OK". At runtime, after causing button B 1 to be instantiated, runtime engine 116 sends a message to dispatcher 140 that indicates that the Label property of button B 1 should be set to "OK".
Dispatcher 140 forwards this message to message handler 128, which invokes the appropriate routine of view 134 to cause the Label property of button B 1 to be set to "OK".
According to one embodiment, this process is repeated for each property of button B 1 for which a value was specified during design-time.
Significantly, the actual operation performed by view i 34 in response to a property being set to a value may be completely different than the operation performed by an instance of the default button class in response to the same property being set to the same value. For example, the default button class DefButton may cause the text "OK" to be on the face of a rectangular button in response to the Label property of the button being set to "OK". In contrast, button B1, implemented by user-specified button class MyButton, may cause the button to be in the shape of the letters "OK" in response to the Label property being set to "OK".
During execution of the application, runtime engine 116 may require the current value of a property of a UI component. To determine the value, runtime engine 116 sends to dispatcher 140 a message that identifies the component and specifies the property for which runtime engine 116 requires the current value.
Dispatcher 140 forwards the message to the appropriate message handler, and the message handler responds by invoking the appropriate method of the view that corresponds to the specified component to retrieve the current value of the specified property. The message handler passes the retrieved value back to dispatcher 140, which sends the value in a message back to runtime engine 116.
COMMON INTERFACE
A 4GL programming tool typically provides, for each type of component made available to the application programmer, both ( 1 ) a class implementation for the component-type, and (2) a message handler that works with the class S implementation. It is possible for 4GL programming tool makers to design message handlers to work with their particular class implementations because they are the providers of those class implementations, and therefore know and control the interfaces thereto.
As described above, embodiments of the present invention allow application designers to specify class implementations that are different than the ones provided by the 4GL programming tool makers. According to one embodiment, even when a user has specified a non-default class implementation for a component, the message handler provided by the 4GL programming tool for that type of component is able to work with the specified class implementation.
To properly function with user-specified component class implementations, message handlers must not only know the class file that contains class implementation of the component class, but also the interface of the methods implemented by the component classes. For example, to set the Label property of button B 1, message handler 128 must know the interface of the method, within view 134, that sets the Label property value.
According to one embodiment, the message handlers know the interface of the methods implemented by user-specified component classes because all component class implementations, including both the default class implementations and user-specified class implementations, are designed to implement a common interface, referred to herein as the IView interface. The message handlers, in turn, are designed to make calls to views through the IView interface. Thus, even though it is not known, at the time that message handlers are designed, which class implementations the message handlers will have to work with, the message handlers are still able to function with whatever class irnplementadons are specified by the application designer 110.
According to one embodiment, all user-specified class implementations are designed to support the following interface (IView):
public void init (IHandler handler);
public void destroys;
public Object getProperty(PropertylZ3 id);
public boolean setProperty(PropertyID id, Object value);
public void addListener(Class type, EvenListener listener);
public void removeListener(Class type, EventListener listener);
public void paint(Graphics g);
public void repaint(Rectangle r);
public void add(Object, child, int index);
public void remove(Object child);
public void removeAll();
In the preceding interface, some methods include parameters of type IHandler. IHandler is a data type for storing a value that identifies a specific message handler instance. As mentioned above, the entity that makes calls to the methods in the IView interface is a message handler instance. Thus, for the methods that require an IHandler to be passed as an input variable, the message ha~~dier instance making the call typically passes data that identifies itself. According to one embodiment, for each component, the methods of the Niew interface supplied by the class implementation for that component are invoked by the message handler for that component as follows:
The "init" method is called immediately after the component is constructed.
The "init" method passes the component a reference to its message handler and gives the component a chance to perform any initialization that it requires.
The "destroy" method is called when a component is no longer required.
This method gives the component a chance to free up any system resources that it holds.
The "getProperty" method returns the value of the requested property.
According to one embodiment, all component implementations for a particular component type are designed to support certain properties. If the specified property is not supported by the component, this getProperty method returns Property.NOT SUPPORTED.
The "setProperty" method sets the value of the specified property. If the specified property is not supported by the component, this method returns false, otherwise it returns true.
The "addListener" method adds a listener of the specified type. According to one embodiment, all component implementations for a particular component type are designed to support certain types of Listener.
The "removeListener" method removes a listener of the specified type.
In the "paint" method, the View must paint itself using the Graphics object specified in the parameter. According to one embodiment, components may include other components. A component that contains other components is referred to as a "Container". For components that are part of a Container, the "paint" method is called by the component's Container. For other components, the "paint" method is called by the component's message handler.
In the "repaint" method, the View invalidates the rectangle provided. If the rectangle is null, the entire object is invalidated.
The "add" method adds a child component to another component. For Containers, the child is of type IView , where IView is the class from which all Views are derived. For lists, the child is of type String. If the index is -l, the child is added at the end of the list. If the index is greater than the current number of children or less than -1, the method will fail.
The "remove" method removes a child from the specified IView. For Containers the child is of type IView. For lists the child is of type String.
The "removeAll method" removes all children from the specified IView.
When an application designer desires to use a class that does not support the IView interface, the application designer may simply define a subclass of that class, where the subclass does support the IView interface. For example, assume that the application designer wants to create an application that implements button B 1 as an instance of a CoolButton class provided by a third party, where the CoolButton class does not implement the Niew interface. Under these circumstances, the application designer (1) declares a subclass of CoolButton that implements the Niew interface, and (2) specifies the implementations of each of the methods of the Niew interface.
The following is an example of how a button class MyButton, which is a subclass that implements the Niew interface, may be declared:
public class MyButton extends CoolButton implements Niew ( [implementations of Niew methods]
The "implementations of the Niew methods" generally convert calls made through the Niew interface to calls made through the interface supported by CoolButton. For example, in one embodiment, the method setProperty(id, value) of the Niew interface is used to set all properties of a view. Thus, a call to set the label of a button through the Niew interface would have the form setProperty(Label, value). Similarly, a call to set the color of a button through the Niew interface would have the form setProperty(Color, value). However, the CoolButton class may implement a method "setText(value)" to set the label of a button, and a method "setColor(value)" to set the color of a button. Under these conditions, the implementation provided by the MyButton class for the setProperty method of the Niew interface may be, for example:
setProperty(id, value) switch(id) case Label:
MyButton.setText(value);
break;
case Color:
MyButton. setColor(value);
S break;
Thus, a call through the IView interface to setProperty is converted to a call to setText when the id value passed to setProperty is "label", and is converted to a call to setColor when the id value passed to setProperty is "color".
ALTERNATIVE EMBODIMENTS
For the purpose of explanation, embodiment-specific details have been included in the foregoing description. However, those details are not required to practice the invention, and are not intended to limit the invention in any way. For example, the invention may be practiced using alternative embodiments, some of which shall now be described.
In the embodiment described above, all component implementations present the same interface to message handlers. However, in alternative embodiments, all user-specified class implementations for each given component type support the same interface as the default class implementation of the given component type, but those interfaces may differ for different types of components. For example, a user-specified class implementation for a button would implement the same interface as the default class implementation for buttons (and therefore be able to function properly with the button message handler), and a user-specified class implementation for a check box would implement the same interface as the default class implementation for a check box (and therefore be able to function properly with the check box message handler}. However, the interface for the button implementations could be different from the interface for the check box implementations.
1n the embodiments described above, UI components (e.g. buttons and check boxes) where given as examples of the types of components made available to a programmer, and for which the 4GL programmer is now able to specify non-default implementations. However, UI components are merely one type of component provided by 4GL programming tools. Other types of components include, for example, components that represent data sources. Using the techniques described herein, a 4GL programming tool may be provided that allows users to specify non-default implementations for any type of application component, including those that are not visibly part of the application's user interface. Similarly, the components for which 4GL programmers may specify non-default implementation classes may be components that execute on the server-side, as well as components that execute on the client-side.
HARDWARE OVERVIEW
Figure 2 is a block diagram that illustrates a computer system 200 upon which an embodiment of the invention may be implemented. Computer system 200 includes a bus 202 or other communication mechanism for communicating information, and a processor 204 coupled with bus 202 for processing information.
Computer system 200 also includes a main memory 206, such as a random access memory (RAM) or other dynamic storage device, coupled to bus 202 for storing information and instructions to be executed by processor 204. Main memory 206 also may be used for storing temporary variables or other intermediate information during execution of instructions to be executed by processor 204. Computer system 200 further includes a read only memory (ROM) 208 or other static storage device coupled to bus 202 for storing static information and instructions for processor 204.
A storage device 210, such as a magnetic disk or optical disk, is provided and coupled to bus 202 for storing information and instructions.
Computer system 200 may be coupled via bus 202 to a display 212, such as a cathode ray tube (CRT), for displaying information to a computer user. An input device 214, including alphanumeric and other keys, is coupled to bus 202 for communicating information and command selections to processor 204. Another type of user input device is cursor control 216, such as a mouse, a trackball, or cursor direction keys for communicating direction information and command selections to processor 204 and for controlling cursor movement on display 212. This input device typically has two degrees of freedom in two axes, a first axis (e.g., x) and a second axis (e.g., y), that allows the device to specify positions in a plane.
The invention is related to the use of computer system 200 for designing 4GL
applications. According to one embodiment of the invention, a 4GL programming tool that allows application programmers to specify non-default implementations of component classes is provided by computer system 200 in response to processor executing one or more sequences of one or more instructions contained in main memory 206. Such instructions may be read into main memory 206 from another computer-readable medium, such as storage device 210. Execution of the sequences of instructions contained in main memory 206 causes processor 204 to perform the process steps described herein. In alternative embodiments, hard-wired circuitry may be used in place of or in combination with software instructions to implement the invention. Thus, embodiments of the invention are not limited to any specific combination of hardware circuitry and software.
The term "computer-readable medium" as used herein refers to any medium that participates in providing instructions to processor 204 for execution.
Such a medium may take many forms, including but not limited to, non-volatile media, volatile media, and transmission media. Non-volatile media includes, for example, optical or magnetic disks, such as storage device 210. Volatile media includes dynamic memory, such as main memory 206. Transmission media includes coaxial cables, copper wire and fiber optics, including the wires that comprise bus 202.
Transmission media can also take the form of acoustic or light waves, such as those generated during radio-wave and infra-red data communications.
Common forms of computer-readable media include, for example, a floppy disk, a flexible disk, hard disk, magnetic tape, or any other magnetic medium, a CD-ROM, any other optical medium, punchcards, papertape, any other physical medium with patterns of holes, a RAM, a PROM, and EPROM, a FLASH-EPROM, any other memory chip or cartridge, a carrier wave as described hereinafter, or any other medium from which a computer can read.
Various forms of computer readable media may be involved in carrying one or more sequences of one or more instructions to processor 204 for execution.
For example, the instructions may initially be carried on a magnetic disk of a remote computer. The remote computer can load the instructions into its dynamic memory and send the instructions over a telephone Iine using a modem. A modem local to computer system 200 can receive the data on the telephone line and use an infra-red transmitter to convert the data to an infra-red signal. An infra-red detector can receive the data carried in the infra-red signal and appropriate circuitry can place the data on bus 202. Bus 202 carnes the data to main memory 206, from which processor 204 retrieves and executes the instructions. The instructions received by S main memory 206 may optionally be stored on storage device 210 either before or after execution by processor 204.
Computer system 200 also includes a communication interface 218 coupled to bus 202. Communication interface 218 provides a two-way data communication coupling to a network Iink 220 that is connected to a local network 222. For example, communication interface 218 may be an integrated services digital network (ISDN) card or a modem to provide a data communication connection to a corresponding type of telephone line. As another example, communication interface 218 may be a local area network (LAN) card to provide a data communication connection to a compatible LAN. Wireless links may also be implemented. In any such implementation, communication interface 218 sends and receives electrical, electromagnetic or optical signals that carry digital data streams representing various types of information.
Network link 220 typically provides data communication through one or more networks to other data devices. For example, network link 220 may provide a connection through local network 222 to a host computer 224 or to data equipment operated by an Internet Service Provider (ISP) 226. ISP 226 in turn provides data communication services through the world wide packet data communication network now commonly referred to as the "Internet" 228. Local network 222 and Internet 228 both use electrical, electromagnetic or optical signals that carry digital data streams. The signals through the various networks and the signals on network link 220 and through communication interface 218, which carry the digital data to and from computer system 200, are exemplary forms of carrier waves transporting the information.
Computer system 200 can send messages and receive data, including program code, through the network(s), network link 220 and communication interface 218. In the Internet example, a server 230 might transmit a requested code for an application program through Internet 228, ISP 226, local network 222 and communication interface 218. In accordance with the invention, one such downloaded application provides for a 4GL programming tool as described herein.
The received code may be executed by processor 204 as it is received, and/or stored in storage device 210, or other non-volatile storage for later execution. In this S manner, computer system 200 may obtain application code in the form of a carrier wave.
In the foregoing specification, the invention has been described with reference to specific embodiments thereof. It will, however, be evident that various modifications and changes may be made thereto without departing from the broader spirit and scope of the invention. The specification and drawings are, accordingly, to be regarded in an illustrative rather than a restrictive sense.
programming tool to design applications visually by selecting user interface components, placing the selected user interface components into a window, and specifying property values for those components. However, unlike conventional 4GL programming tools, one component property that is controlled by the S application designer is the implementation class of the component. The value to which the application designer sets the implementation class properly of a component dictates the object class that defines the properties and methods that will be executed at runtime to implement the component. The specified implementation class far a button may be, for example, the standard button class provided by the 4GL programming tool, or a custom designed oval button class written by the application designer or by a third party component developer.
During runtime, methods in the specified implementation class are invoked to instantiate the component and to set and read properties of the component. To correctly invoke those methods, the interfaces of the methods must be known to the entity performing the invocations. Therefore, according to one aspect of the invention, each of component implementations that are to be used by the application, including both the "standard" component implementations in the library provided with the 4GL programming tool and the "custom" component implementations specified by the application designer, implements a common interface.
Figure 1 illustrates a 4GL system 100 according to an embodiment of the invention. The 4GL system 100 includes a 4GL programming tool 112 that an application designer 110 uses to generate application code I 14 that defines an application program. As mentioned above, the application code I 14 may be in a form that is directly executable by a machine, may be in a form that is executable by a virtual machine, or may simply be metadata that describes the application.
In the illustrated embodiment, the application code 114 is in a form that is used by a runtime engine 116 to implement the invention.
At run-time, the application code 114 is "executed" by a runtime engine 116.
Depending on the nature of the application code 114, the process of executing the application code I 14 may, for example, involve interpreting instructions contained in the application code 114 or calling routines that implement application components that are described in the application code 114.
In the illustrated system 100, the applicarion is implemented in a client/server model, where portions of the application run on a server, and other portions of the application run on a client. Typically, the server-side components are on a different machine than the client-side components, and communication between the two sets of components is performed over a network connection.
The server-side components of the application include the application code 114 and the runtime engine 116. The client-side components of the application include components that implement the user interface of the application that is displayed to an application user 124. Those components include a dispatcher 140, message handlers, and views. The illustrated embodiment is shown with three message handlers 128, 130 and 132 and three views 134, 136 and 138.
Each component of the application's user interface has a corresponding view and message handler. For example, assume that the user interface of the application includes a button B 1 and two checkboxes CB 1 and CB2. View 134 and message handler 128 may correspond to the button B1, view 136 and message handler 130 may correspond to the first check box CB1, and view 138 and handler 132 may correspond to the second check box CB2.
A view is an instance of the implementation class of a component. Thus, the view that corresponds to a component includes the code that implements the component. For example, view 134 is an instance of the implementation class that implements button B1. Similarly, views 136 and 138 are instances of the implementation classes that implement check boxes CB l and CB2, respectively.
The views 136 and 138 for check boxes CB1 and CB2 will not contain the same code if, for example, CB 1 is implemented using the default check box implementation class, while CB2 is implemented using a user-specified check box implementation class.
Under those conditions, the code implementing CB 1 would typically be contained in a runtime library distributed with 4GL programming tool 112, while the code implementing CB2 would be implemented in a separate file.
Each type of component has a corresponding type of message handler. The message handler type for a given component type is designed to handle the type of messages associated with that component type. For example, a button message WO 00/72140 PC'T/US00114624 handler listens for and handles the type of messages buttons receive, while a check box message handler listens for and handles the type of messages check boxes receive.
The message handler that corresponds to a component sends messages S relating to events involving the component back to the runtime engine 116.
For example, message handler 128 may detect that the user has clicked on button B
1. In response to detecting the click, the message handler 128 sends a message through dispatcher 140 to runtime engine I 16, making the runtime engine 116 aware that button B 1 has been clicked.
The message handler that corresponds to a component also invokes methods provided by the component's view in response to messages from the runtime engine 116. For example, message handler 128 may respond to a message from runtime engine 116 by calling a method provided by view 134 that changes the color of button B 1.
OPERATION OF RUN-TIME ENVIRONMENT
At runtime, the runtime engine 116 reads and executes the application code 114 that was previously generated by the 4GL programming tool 112. That application code 114 includes data that identifies the implementation class of the application components for which the application designer I 10 specified an implementation class. For example, assume that the default implementation class for buttons is DefButton.class. During application design, the application designer 110 may have specified a different implementation class for the B 1 button that is to be displayed on the user interface of the application. For the purpose of explanation, it shall be assumed that the application designer 110 specified the implementation class of button B 1 to be MyButton.class. Under these conditions, the application code 114 includes data that indicates that the implementation class of B 1 is MyButton.class.
During execution of the application code 114, the runtime engine I 16 sends messages to the dispatcher 140 to cause the creation of the components specified in the application code I 14. For at least those components that do not use the default class implementations, the messages sent by runtime engine 116 include information that identifies the implementation class. For example, it shall be assumed that runtime engine 116 sends a message to dispatcher 140 that requests the creation of button B1 using implementation class MyButton.class.
When dispatcher 140 receives a message from runtime engine 116, dispatcher 140 forwards the message to the message handler that corresponds to the component identified in the message. If a message handler has not yet been initiated for the component identified in the message, then the dispatcher 140 instanHates a message handler of the appropriate component type for the component. For example, if the message received by dispatcher 140 calls for the creation of a button (e.g.
button B 1 ), and a message handler for that particular button has not been instantiated, then I O dispatcher 140 instantiates a button-type message handler (e.g. message handler 128) for the button. After instantiating the appropriate message handler, the dispatcher 140 sends the message to message handler.
When a message handler receives a message to create a component, the message handler determines, based on information contained in the message, 1 S whether the component is implemented using the default class implementation. If the component is implemented using the default class implementation, then the message handler calls the method that instantiates components (i.e. the "constructor") provided by the default class implementation for that type of component. This is typically performed by calling a method in the runtime library 20 provided with 4GL programming tool 112. If the component is implemented using a user-specified class implementation, then the message handler calls the constructor provided by the user-specified class implementation.
For example, in response to a message requesting the instantiation of button B 1, message handler 128 determines that button B 1 is implemented using the user 25 specified implementation class MyButton.class. Message handler 128 would therefore call the constructor provided by the MyButton.class implementation class to instantiate button B 1. Instantiating button B 1 creates an instance of the class MyButton, which is depicted as view 134.
Once a client-side component has been instantiated, the properties of the 30 component must be set to the values specified for the component by the application designer 110. The values for the properties of the component are reflected in the application code 114 generated by the 4GL programming tool 112. After causing the component to be instantiated, the runtime engine 116 sends messages to dispatcher -g_ 140 that indicate the values of the properties of the component. Dispatcher forwards those messages to the message handler that corresponds to the component, and the message handler invokes the appropriate method of the component's view to set the specified property to the specified value.
For example, assume that application designer 110 assigned the value "OK"
to the "Label" property of button B 1. Under these conditions, the application code 114 generated by 4GL programming tool 112 would indicate that the Label property of button B 1 has been assigned the value "OK". At runtime, after causing button B 1 to be instantiated, runtime engine 116 sends a message to dispatcher 140 that indicates that the Label property of button B 1 should be set to "OK".
Dispatcher 140 forwards this message to message handler 128, which invokes the appropriate routine of view 134 to cause the Label property of button B 1 to be set to "OK".
According to one embodiment, this process is repeated for each property of button B 1 for which a value was specified during design-time.
Significantly, the actual operation performed by view i 34 in response to a property being set to a value may be completely different than the operation performed by an instance of the default button class in response to the same property being set to the same value. For example, the default button class DefButton may cause the text "OK" to be on the face of a rectangular button in response to the Label property of the button being set to "OK". In contrast, button B1, implemented by user-specified button class MyButton, may cause the button to be in the shape of the letters "OK" in response to the Label property being set to "OK".
During execution of the application, runtime engine 116 may require the current value of a property of a UI component. To determine the value, runtime engine 116 sends to dispatcher 140 a message that identifies the component and specifies the property for which runtime engine 116 requires the current value.
Dispatcher 140 forwards the message to the appropriate message handler, and the message handler responds by invoking the appropriate method of the view that corresponds to the specified component to retrieve the current value of the specified property. The message handler passes the retrieved value back to dispatcher 140, which sends the value in a message back to runtime engine 116.
COMMON INTERFACE
A 4GL programming tool typically provides, for each type of component made available to the application programmer, both ( 1 ) a class implementation for the component-type, and (2) a message handler that works with the class S implementation. It is possible for 4GL programming tool makers to design message handlers to work with their particular class implementations because they are the providers of those class implementations, and therefore know and control the interfaces thereto.
As described above, embodiments of the present invention allow application designers to specify class implementations that are different than the ones provided by the 4GL programming tool makers. According to one embodiment, even when a user has specified a non-default class implementation for a component, the message handler provided by the 4GL programming tool for that type of component is able to work with the specified class implementation.
To properly function with user-specified component class implementations, message handlers must not only know the class file that contains class implementation of the component class, but also the interface of the methods implemented by the component classes. For example, to set the Label property of button B 1, message handler 128 must know the interface of the method, within view 134, that sets the Label property value.
According to one embodiment, the message handlers know the interface of the methods implemented by user-specified component classes because all component class implementations, including both the default class implementations and user-specified class implementations, are designed to implement a common interface, referred to herein as the IView interface. The message handlers, in turn, are designed to make calls to views through the IView interface. Thus, even though it is not known, at the time that message handlers are designed, which class implementations the message handlers will have to work with, the message handlers are still able to function with whatever class irnplementadons are specified by the application designer 110.
According to one embodiment, all user-specified class implementations are designed to support the following interface (IView):
public void init (IHandler handler);
public void destroys;
public Object getProperty(PropertylZ3 id);
public boolean setProperty(PropertyID id, Object value);
public void addListener(Class type, EvenListener listener);
public void removeListener(Class type, EventListener listener);
public void paint(Graphics g);
public void repaint(Rectangle r);
public void add(Object, child, int index);
public void remove(Object child);
public void removeAll();
In the preceding interface, some methods include parameters of type IHandler. IHandler is a data type for storing a value that identifies a specific message handler instance. As mentioned above, the entity that makes calls to the methods in the IView interface is a message handler instance. Thus, for the methods that require an IHandler to be passed as an input variable, the message ha~~dier instance making the call typically passes data that identifies itself. According to one embodiment, for each component, the methods of the Niew interface supplied by the class implementation for that component are invoked by the message handler for that component as follows:
The "init" method is called immediately after the component is constructed.
The "init" method passes the component a reference to its message handler and gives the component a chance to perform any initialization that it requires.
The "destroy" method is called when a component is no longer required.
This method gives the component a chance to free up any system resources that it holds.
The "getProperty" method returns the value of the requested property.
According to one embodiment, all component implementations for a particular component type are designed to support certain properties. If the specified property is not supported by the component, this getProperty method returns Property.NOT SUPPORTED.
The "setProperty" method sets the value of the specified property. If the specified property is not supported by the component, this method returns false, otherwise it returns true.
The "addListener" method adds a listener of the specified type. According to one embodiment, all component implementations for a particular component type are designed to support certain types of Listener.
The "removeListener" method removes a listener of the specified type.
In the "paint" method, the View must paint itself using the Graphics object specified in the parameter. According to one embodiment, components may include other components. A component that contains other components is referred to as a "Container". For components that are part of a Container, the "paint" method is called by the component's Container. For other components, the "paint" method is called by the component's message handler.
In the "repaint" method, the View invalidates the rectangle provided. If the rectangle is null, the entire object is invalidated.
The "add" method adds a child component to another component. For Containers, the child is of type IView , where IView is the class from which all Views are derived. For lists, the child is of type String. If the index is -l, the child is added at the end of the list. If the index is greater than the current number of children or less than -1, the method will fail.
The "remove" method removes a child from the specified IView. For Containers the child is of type IView. For lists the child is of type String.
The "removeAll method" removes all children from the specified IView.
When an application designer desires to use a class that does not support the IView interface, the application designer may simply define a subclass of that class, where the subclass does support the IView interface. For example, assume that the application designer wants to create an application that implements button B 1 as an instance of a CoolButton class provided by a third party, where the CoolButton class does not implement the Niew interface. Under these circumstances, the application designer (1) declares a subclass of CoolButton that implements the Niew interface, and (2) specifies the implementations of each of the methods of the Niew interface.
The following is an example of how a button class MyButton, which is a subclass that implements the Niew interface, may be declared:
public class MyButton extends CoolButton implements Niew ( [implementations of Niew methods]
The "implementations of the Niew methods" generally convert calls made through the Niew interface to calls made through the interface supported by CoolButton. For example, in one embodiment, the method setProperty(id, value) of the Niew interface is used to set all properties of a view. Thus, a call to set the label of a button through the Niew interface would have the form setProperty(Label, value). Similarly, a call to set the color of a button through the Niew interface would have the form setProperty(Color, value). However, the CoolButton class may implement a method "setText(value)" to set the label of a button, and a method "setColor(value)" to set the color of a button. Under these conditions, the implementation provided by the MyButton class for the setProperty method of the Niew interface may be, for example:
setProperty(id, value) switch(id) case Label:
MyButton.setText(value);
break;
case Color:
MyButton. setColor(value);
S break;
Thus, a call through the IView interface to setProperty is converted to a call to setText when the id value passed to setProperty is "label", and is converted to a call to setColor when the id value passed to setProperty is "color".
ALTERNATIVE EMBODIMENTS
For the purpose of explanation, embodiment-specific details have been included in the foregoing description. However, those details are not required to practice the invention, and are not intended to limit the invention in any way. For example, the invention may be practiced using alternative embodiments, some of which shall now be described.
In the embodiment described above, all component implementations present the same interface to message handlers. However, in alternative embodiments, all user-specified class implementations for each given component type support the same interface as the default class implementation of the given component type, but those interfaces may differ for different types of components. For example, a user-specified class implementation for a button would implement the same interface as the default class implementation for buttons (and therefore be able to function properly with the button message handler), and a user-specified class implementation for a check box would implement the same interface as the default class implementation for a check box (and therefore be able to function properly with the check box message handler}. However, the interface for the button implementations could be different from the interface for the check box implementations.
1n the embodiments described above, UI components (e.g. buttons and check boxes) where given as examples of the types of components made available to a programmer, and for which the 4GL programmer is now able to specify non-default implementations. However, UI components are merely one type of component provided by 4GL programming tools. Other types of components include, for example, components that represent data sources. Using the techniques described herein, a 4GL programming tool may be provided that allows users to specify non-default implementations for any type of application component, including those that are not visibly part of the application's user interface. Similarly, the components for which 4GL programmers may specify non-default implementation classes may be components that execute on the server-side, as well as components that execute on the client-side.
HARDWARE OVERVIEW
Figure 2 is a block diagram that illustrates a computer system 200 upon which an embodiment of the invention may be implemented. Computer system 200 includes a bus 202 or other communication mechanism for communicating information, and a processor 204 coupled with bus 202 for processing information.
Computer system 200 also includes a main memory 206, such as a random access memory (RAM) or other dynamic storage device, coupled to bus 202 for storing information and instructions to be executed by processor 204. Main memory 206 also may be used for storing temporary variables or other intermediate information during execution of instructions to be executed by processor 204. Computer system 200 further includes a read only memory (ROM) 208 or other static storage device coupled to bus 202 for storing static information and instructions for processor 204.
A storage device 210, such as a magnetic disk or optical disk, is provided and coupled to bus 202 for storing information and instructions.
Computer system 200 may be coupled via bus 202 to a display 212, such as a cathode ray tube (CRT), for displaying information to a computer user. An input device 214, including alphanumeric and other keys, is coupled to bus 202 for communicating information and command selections to processor 204. Another type of user input device is cursor control 216, such as a mouse, a trackball, or cursor direction keys for communicating direction information and command selections to processor 204 and for controlling cursor movement on display 212. This input device typically has two degrees of freedom in two axes, a first axis (e.g., x) and a second axis (e.g., y), that allows the device to specify positions in a plane.
The invention is related to the use of computer system 200 for designing 4GL
applications. According to one embodiment of the invention, a 4GL programming tool that allows application programmers to specify non-default implementations of component classes is provided by computer system 200 in response to processor executing one or more sequences of one or more instructions contained in main memory 206. Such instructions may be read into main memory 206 from another computer-readable medium, such as storage device 210. Execution of the sequences of instructions contained in main memory 206 causes processor 204 to perform the process steps described herein. In alternative embodiments, hard-wired circuitry may be used in place of or in combination with software instructions to implement the invention. Thus, embodiments of the invention are not limited to any specific combination of hardware circuitry and software.
The term "computer-readable medium" as used herein refers to any medium that participates in providing instructions to processor 204 for execution.
Such a medium may take many forms, including but not limited to, non-volatile media, volatile media, and transmission media. Non-volatile media includes, for example, optical or magnetic disks, such as storage device 210. Volatile media includes dynamic memory, such as main memory 206. Transmission media includes coaxial cables, copper wire and fiber optics, including the wires that comprise bus 202.
Transmission media can also take the form of acoustic or light waves, such as those generated during radio-wave and infra-red data communications.
Common forms of computer-readable media include, for example, a floppy disk, a flexible disk, hard disk, magnetic tape, or any other magnetic medium, a CD-ROM, any other optical medium, punchcards, papertape, any other physical medium with patterns of holes, a RAM, a PROM, and EPROM, a FLASH-EPROM, any other memory chip or cartridge, a carrier wave as described hereinafter, or any other medium from which a computer can read.
Various forms of computer readable media may be involved in carrying one or more sequences of one or more instructions to processor 204 for execution.
For example, the instructions may initially be carried on a magnetic disk of a remote computer. The remote computer can load the instructions into its dynamic memory and send the instructions over a telephone Iine using a modem. A modem local to computer system 200 can receive the data on the telephone line and use an infra-red transmitter to convert the data to an infra-red signal. An infra-red detector can receive the data carried in the infra-red signal and appropriate circuitry can place the data on bus 202. Bus 202 carnes the data to main memory 206, from which processor 204 retrieves and executes the instructions. The instructions received by S main memory 206 may optionally be stored on storage device 210 either before or after execution by processor 204.
Computer system 200 also includes a communication interface 218 coupled to bus 202. Communication interface 218 provides a two-way data communication coupling to a network Iink 220 that is connected to a local network 222. For example, communication interface 218 may be an integrated services digital network (ISDN) card or a modem to provide a data communication connection to a corresponding type of telephone line. As another example, communication interface 218 may be a local area network (LAN) card to provide a data communication connection to a compatible LAN. Wireless links may also be implemented. In any such implementation, communication interface 218 sends and receives electrical, electromagnetic or optical signals that carry digital data streams representing various types of information.
Network link 220 typically provides data communication through one or more networks to other data devices. For example, network link 220 may provide a connection through local network 222 to a host computer 224 or to data equipment operated by an Internet Service Provider (ISP) 226. ISP 226 in turn provides data communication services through the world wide packet data communication network now commonly referred to as the "Internet" 228. Local network 222 and Internet 228 both use electrical, electromagnetic or optical signals that carry digital data streams. The signals through the various networks and the signals on network link 220 and through communication interface 218, which carry the digital data to and from computer system 200, are exemplary forms of carrier waves transporting the information.
Computer system 200 can send messages and receive data, including program code, through the network(s), network link 220 and communication interface 218. In the Internet example, a server 230 might transmit a requested code for an application program through Internet 228, ISP 226, local network 222 and communication interface 218. In accordance with the invention, one such downloaded application provides for a 4GL programming tool as described herein.
The received code may be executed by processor 204 as it is received, and/or stored in storage device 210, or other non-volatile storage for later execution. In this S manner, computer system 200 may obtain application code in the form of a carrier wave.
In the foregoing specification, the invention has been described with reference to specific embodiments thereof. It will, however, be evident that various modifications and changes may be made thereto without departing from the broader spirit and scope of the invention. The specification and drawings are, accordingly, to be regarded in an illustrative rather than a restrictive sense.
Claims (24)
PROPERTY OR PRIVILEGE IS CLAIMED ARE DEFINED AS FOLLOWS:
1. A method for executing an application designed by a 4GL programming tool, the method comprising the steps of:
reading, from application code generated by the 4GL programming tool, a portion of said application code that a) identifies a component for the application, wherein the component is of a particular component-type for which the 4GL programming tool provides a first implementation; and b) identifies a second implementation for the component that is different from said first implementation and that is not an implementation provided by said 4GL
programming tool;
executing said portion of said application code by calling a constructor implemented in said second implementation to create the component within the application.
reading, from application code generated by the 4GL programming tool, a portion of said application code that a) identifies a component for the application, wherein the component is of a particular component-type for which the 4GL programming tool provides a first implementation; and b) identifies a second implementation for the component that is different from said first implementation and that is not an implementation provided by said 4GL
programming tool;
executing said portion of said application code by calling a constructor implemented in said second implementation to create the component within the application.
2. The method of claim 1 wherein:
the step of reading is performed by a runtime engine residing on a server; and the step of calling the constructor is performed on a client in response to receipt at said client of a message generated by said runtime engine in response to executing said portion of said application code.
the step of reading is performed by a runtime engine residing on a server; and the step of calling the constructor is performed on a client in response to receipt at said client of a message generated by said runtime engine in response to executing said portion of said application code.
3. The method of claim 2 wherein:
the first implementation and the second implementation both support a common interface;
and the step of calling the constructor is performed through said common interface by a message handler for said particular component-type.
the first implementation and the second implementation both support a common interface;
and the step of calling the constructor is performed through said common interface by a message handler for said particular component-type.
4. The method of claim 1 wherein:
the 4GL programming tool generates said portion of the application code in response to an application programmer entering input that specifies that said application is to have a component of said particular component-type; and said application programmer entering input that specifies that said component is to be implemented using said second implementation.
the 4GL programming tool generates said portion of the application code in response to an application programmer entering input that specifies that said application is to have a component of said particular component-type; and said application programmer entering input that specifies that said component is to be implemented using said second implementation.
5. The method of claim 2 wherein:
the runtime engine executes said portion of said application code by sending a message to a dispatcher;
the dispatcher responds to the message by instantiating a message handler for said particular component-type; and the message handler invokes said constructor.
the runtime engine executes said portion of said application code by sending a message to a dispatcher;
the dispatcher responds to the message by instantiating a message handler for said particular component-type; and the message handler invokes said constructor.
6. The method of claim 5 wherein:
the runtime engine is on a server;
the dispatcher is on a client operatively coupled to said server over a network; and the runtime engine sends the message to the dispatcher over said network.
the runtime engine is on a server;
the dispatcher is on a client operatively coupled to said server over a network; and the runtime engine sends the message to the dispatcher over said network.
7. The method of claim 1 further including the steps of:
reading, from application code generated by the 4GL programming tool, a second portion of said application code that a) identifies a second component for the application, wherein the second component is of a second particular component-type for which the 4UL programming tool provides a third implementation, wherein the second component-type is different from said first particular component-type; and b) identifies a fourth implementation for the second component that is different from said third implementation;
executing said second portion of said application code by calling a constructor implemented in said fourth implementation to create the second component within the application.
reading, from application code generated by the 4GL programming tool, a second portion of said application code that a) identifies a second component for the application, wherein the second component is of a second particular component-type for which the 4UL programming tool provides a third implementation, wherein the second component-type is different from said first particular component-type; and b) identifies a fourth implementation for the second component that is different from said third implementation;
executing said second portion of said application code by calling a constructor implemented in said fourth implementation to create the second component within the application.
8. The method of claim 7 wherein said first, second, third and fourth implementations all implement a common interface.
9. A method for use in a system that includes a 4GL programming tool that allows application designers to create, through interaction with user interface objects and controls presented by the 4GL
programming tool, applications that contain components that belong to a set of component-types for which implementations are provided by the 4GL programming tool, the method comprising the steps of:
the 4GL programming tool providing a control for receiving data that indicates a user-specified implementation for a component of an application being designed using said 4GL
programming tool;
wherein said component is an instance of a component-type that belongs to said set of component-types;
wherein said user-defined implementation is not one of said implementations provided by the 4GL programming tool;
the 4GL programming tool generating application code that, when executed, runs said application; and wherein a portion of said application code indicates that said component is to be implemented using said user-specified implementation.
programming tool, applications that contain components that belong to a set of component-types for which implementations are provided by the 4GL programming tool, the method comprising the steps of:
the 4GL programming tool providing a control for receiving data that indicates a user-specified implementation for a component of an application being designed using said 4GL
programming tool;
wherein said component is an instance of a component-type that belongs to said set of component-types;
wherein said user-defined implementation is not one of said implementations provided by the 4GL programming tool;
the 4GL programming tool generating application code that, when executed, runs said application; and wherein a portion of said application code indicates that said component is to be implemented using said user-specified implementation.
10. The method of claim 9 wherein said control is one of a plurality of controls on a property palette for receiving user-specified values for a plurality of properties of said component.
11. The method of claim 9 wherein the step of generating application code includes generating application code that is interpreted by a runtime engine to execute said application.
12. The method of claim 11 wherein:
the implementations provided by the 4GL programming tool for the set of component-types each support a common interface;
the user-specified implementation supports said common interface; and during execution of the application, said component and any components implemented using the implementations provided by the 4GL programming tool are instantiated through calls made through said common interface.
the implementations provided by the 4GL programming tool for the set of component-types each support a common interface;
the user-specified implementation supports said common interface; and during execution of the application, said component and any components implemented using the implementations provided by the 4GL programming tool are instantiated through calls made through said common interface.
13. A computer-readable medium carrying one or more sequences of instructions for executing an application designed by a 4GL programming tool, wherein execution of the one or more sequences of instructions by one or more processors causes the one or more processors to perform the steps of:
reading, from application code generated by the 4GL programming tool, a portion of said application code that a) identifies a component for the application, wherein the component is of a particular component-type for which the 4GL programming tool provides a first implementation; and b) identifies a second implementation for the component that is different from said first implementation;
executing said portion of said application code by calling a constructor implemented in said second implementation to create the component within the application.
reading, from application code generated by the 4GL programming tool, a portion of said application code that a) identifies a component for the application, wherein the component is of a particular component-type for which the 4GL programming tool provides a first implementation; and b) identifies a second implementation for the component that is different from said first implementation;
executing said portion of said application code by calling a constructor implemented in said second implementation to create the component within the application.
14. The computer-readable medium of claim 13 wherein:
the step of reading is performed by a runtime engine residing on a server; and the step of calling the constructor is performed on a client in response to receipt at said client of a message generated by said runtime engine in response to executing said portion of said application code.
the step of reading is performed by a runtime engine residing on a server; and the step of calling the constructor is performed on a client in response to receipt at said client of a message generated by said runtime engine in response to executing said portion of said application code.
15. The computer-readable medium of claim 14 wherein:
the first implementation and the second implementation both support a common interface;
and the step of calling the constructor is performed through said common interface by a message handler for said particular component-type.
the first implementation and the second implementation both support a common interface;
and the step of calling the constructor is performed through said common interface by a message handler for said particular component-type.
16. The computer-readable medium of claim 13 wherein:
the 4GL programming tool generates said portion of the application code in response to an application programmer entering input that specifies that said application is to have a component of said particular component-type; and said application programmer entering input that specifies that said component is to be implemented using said second implementation.
the 4GL programming tool generates said portion of the application code in response to an application programmer entering input that specifies that said application is to have a component of said particular component-type; and said application programmer entering input that specifies that said component is to be implemented using said second implementation.
17. The computer-readable medium of claim 14 wherein:
the runtime engine executes said portion of said application code by sending a message to a dispatcher;
the dispatcher responds to the message by instantiating a message handler for said particular component-type; and the message handler invokes said constructor.
the runtime engine executes said portion of said application code by sending a message to a dispatcher;
the dispatcher responds to the message by instantiating a message handler for said particular component-type; and the message handler invokes said constructor.
18. The computer-readable medium of claim 17 wherein:
the runtime engine is on a server;
the dispatcher is on a client operatively coupled to said server over a network; and the runtime engine sends the message to the dispatcher over said network.
the runtime engine is on a server;
the dispatcher is on a client operatively coupled to said server over a network; and the runtime engine sends the message to the dispatcher over said network.
19. The computer-readable medium of claim 13 further including instructions for performing the steps of:
reading, from application code generated by the 4GL programming tool, a second portion of said application code that a) identifies a second component for the application, wherein the second component is of a second particular component-type for which the 4GL programming tool provides a third implementation, wherein the second component-type is different from said first particular component-type; and b) identifies a fourth implementation for the second component that is different from said third implementation;
executing said second portion of said application code by calling a constructor implemented in said fourth implementation to create the second component within the application.
reading, from application code generated by the 4GL programming tool, a second portion of said application code that a) identifies a second component for the application, wherein the second component is of a second particular component-type for which the 4GL programming tool provides a third implementation, wherein the second component-type is different from said first particular component-type; and b) identifies a fourth implementation for the second component that is different from said third implementation;
executing said second portion of said application code by calling a constructor implemented in said fourth implementation to create the second component within the application.
20. The method of claim 19 wherein said first, second, third and fourth implementations all implement a common interface.
21. A computer-readable medium carrying instructions to implement a 4GL
programming tool that allows application designers to create, through interaction with user interface objects and controls presented by the 4GL programming tool, applications that contain components that belong to a set of component-types for which implementations are provided by the 4GL
programming tool, the computer-readable medium carrying instructions for performing the steps of:
the 4GL programming tool providing a control for receiving data that indicates a user-specified implementation for a component of an application being designed using said 4GL
programming tool;
wherein said component is an instance of a component-type that belongs to said set of component-types;
wherein said user-defined implementation is not one of said implementations provided by the 4GL programming tool;
the 4GL programming tool generating application code that, when executed, runs said application; and wherein a portion of said application code indicates that said component is to be implemented using said user-specified implementation.
programming tool that allows application designers to create, through interaction with user interface objects and controls presented by the 4GL programming tool, applications that contain components that belong to a set of component-types for which implementations are provided by the 4GL
programming tool, the computer-readable medium carrying instructions for performing the steps of:
the 4GL programming tool providing a control for receiving data that indicates a user-specified implementation for a component of an application being designed using said 4GL
programming tool;
wherein said component is an instance of a component-type that belongs to said set of component-types;
wherein said user-defined implementation is not one of said implementations provided by the 4GL programming tool;
the 4GL programming tool generating application code that, when executed, runs said application; and wherein a portion of said application code indicates that said component is to be implemented using said user-specified implementation.
22. The computer-readable medium of claim 21 wherein said control is one of a plurality of controls on a property palette for receiving user-specified values for a plurality of properties of said component.
23. The computer-readable medium of claim 21 wherein the step of generating application code includes generating application code that is interpreted by a runtime engine to execute said application.
24. The computer-readable medium of claim 23 wherein:
the implementations provided by the 4GL programming tool for the set of component-types each support a common interface;
the user-specified implementation supports said common interface; and during execution of the application, said component and any components implemented using the implementations provided by the 4GL programming tool are instantiated through calls made through said common interface.
the implementations provided by the 4GL programming tool for the set of component-types each support a common interface;
the user-specified implementation supports said common interface; and during execution of the application, said component and any components implemented using the implementations provided by the 4GL programming tool are instantiated through calls made through said common interface.
Applications Claiming Priority (3)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| US09/318,518 | 1999-05-25 | ||
| US09/318,518 US6560770B1 (en) | 1999-05-25 | 1999-05-25 | Extending the attributes of an application generated using a fourth generation programming tool |
| PCT/US2000/014624 WO2000072140A2 (en) | 1999-05-25 | 2000-05-25 | Extending the attributes of an application generated using a fourth generation programming tool |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| CA2365572A1 CA2365572A1 (en) | 2000-11-30 |
| CA2365572C true CA2365572C (en) | 2004-07-20 |
Family
ID=23238510
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CA002365572A Expired - Lifetime CA2365572C (en) | 1999-05-25 | 2000-05-25 | Extending the attributes of an application generated using a fourth generation programming tool |
Country Status (9)
| Country | Link |
|---|---|
| US (1) | US6560770B1 (en) |
| EP (1) | EP1192532B1 (en) |
| JP (3) | JP2003500739A (en) |
| AT (1) | ATE235079T1 (en) |
| AU (1) | AU777692B2 (en) |
| CA (1) | CA2365572C (en) |
| DE (1) | DE60001743T2 (en) |
| HK (1) | HK1041732B (en) |
| WO (1) | WO2000072140A2 (en) |
Families Citing this family (12)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US6880126B1 (en) | 1999-08-03 | 2005-04-12 | International Business Machines Corporation | Controlling presentation of a GUI, using view controllers created by an application mediator, by identifying a destination to access a target to retrieve data |
| US6779177B1 (en) | 1999-10-28 | 2004-08-17 | International Business Machines Corporation | Mechanism for cross channel multi-server multi-protocol multi-data model thin clients |
| US7181686B1 (en) | 1999-10-29 | 2007-02-20 | International Business Machines Corporation | Selecting screens in a GUI using events generated by a set of view controllers |
| US6862686B1 (en) | 1999-10-29 | 2005-03-01 | International Business Machines Corporation | Method and apparatus in a data processing system for the separation of role-based permissions specification from its corresponding implementation of its semantic behavior |
| US6976244B2 (en) | 2002-01-09 | 2005-12-13 | International Business Machines Corporation | Method, system, and product for storage of attribute data in an object oriented environment |
| US20030182458A1 (en) * | 2002-03-22 | 2003-09-25 | Ali Syed M. | Generating a decoupled presentation layer in an application |
| US7240319B2 (en) * | 2003-02-19 | 2007-07-03 | Diversified Systems, Inc. | Apparatus, system, method, and program for facilitating the design of bare circuit boards |
| US7458055B2 (en) * | 2003-02-19 | 2008-11-25 | Diversified Systems, Inc. | Apparatus, system, method, and program for facilitating the design of electronic assemblies |
| US7313448B2 (en) * | 2005-08-15 | 2007-12-25 | Honeywell International Inc. | Method and apparatus for providing a standard control system with custom application capability |
| US8312420B1 (en) | 2005-11-18 | 2012-11-13 | The Mathworks, Inc. | System and method for performing structural templatization |
| US20070168926A1 (en) * | 2005-12-16 | 2007-07-19 | Raghuram Rajah | Software customization framework |
| US8019844B2 (en) * | 2005-12-20 | 2011-09-13 | Level 3 Communications, Llc | System and method for monitoring data in a telecommunications network |
Family Cites Families (11)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US5517645A (en) * | 1993-11-05 | 1996-05-14 | Microsoft Corporation | Method and system for interfacing components via aggregate components formed by aggregating the components each with an instance of a component manager |
| US5875331A (en) * | 1994-09-30 | 1999-02-23 | International Business Machines Corp. | System and method for generating target language code utilizing an object oriented code generator |
| US5617568A (en) * | 1994-12-14 | 1997-04-01 | International Business Machines Corporation | System and method for supporting file attributes on a distributed file system without native support therefor |
| US5911070A (en) * | 1995-08-07 | 1999-06-08 | Inprise Corporation | Development system with methods for bi-directional application program code generation |
| DE19535519C2 (en) * | 1995-09-25 | 1999-03-04 | Ibm | Processes for reducing the size of computer programs |
| US5721929A (en) * | 1995-10-06 | 1998-02-24 | Electronic Data Systems Corporation | Method for extending a fourth generation programming language |
| US5960200A (en) * | 1996-05-03 | 1999-09-28 | I-Cube | System to transition an enterprise to a distributed infrastructure |
| US5949998A (en) * | 1996-07-03 | 1999-09-07 | Sun Microsystems, Inc. | Filtering an object interface definition to determine services needed and provided |
| US5887134A (en) * | 1997-06-30 | 1999-03-23 | Sun Microsystems | System and method for preserving message order while employing both programmed I/O and DMA operations |
| US6237135B1 (en) * | 1998-06-18 | 2001-05-22 | Borland Software Corporation | Development system with visual design tools for creating and maintaining Java Beans components |
| US6167563A (en) * | 1998-09-17 | 2000-12-26 | Unisys Corporation | Method and system for building components in a framework useful in developing integrated business-centric applications |
-
1999
- 1999-05-25 US US09/318,518 patent/US6560770B1/en not_active Expired - Lifetime
-
2000
- 2000-05-25 JP JP2000620467A patent/JP2003500739A/en not_active Withdrawn
- 2000-05-25 CA CA002365572A patent/CA2365572C/en not_active Expired - Lifetime
- 2000-05-25 AT AT00936351T patent/ATE235079T1/en not_active IP Right Cessation
- 2000-05-25 WO PCT/US2000/014624 patent/WO2000072140A2/en active IP Right Grant
- 2000-05-25 AU AU51675/00A patent/AU777692B2/en not_active Expired
- 2000-05-25 DE DE60001743T patent/DE60001743T2/en not_active Expired - Lifetime
- 2000-05-25 EP EP00936351A patent/EP1192532B1/en not_active Expired - Lifetime
-
2002
- 2002-04-23 HK HK02103026.0A patent/HK1041732B/en not_active IP Right Cessation
-
2008
- 2008-01-21 JP JP2008010624A patent/JP5520446B2/en not_active Expired - Lifetime
-
2012
- 2012-06-05 JP JP2012128172A patent/JP5820339B2/en not_active Expired - Lifetime
Also Published As
| Publication number | Publication date |
|---|---|
| DE60001743T2 (en) | 2004-02-05 |
| DE60001743D1 (en) | 2003-04-24 |
| WO2000072140A2 (en) | 2000-11-30 |
| JP5820339B2 (en) | 2015-11-24 |
| EP1192532A2 (en) | 2002-04-03 |
| JP2008171435A (en) | 2008-07-24 |
| ATE235079T1 (en) | 2003-04-15 |
| US6560770B1 (en) | 2003-05-06 |
| AU5167500A (en) | 2000-12-12 |
| JP2012212449A (en) | 2012-11-01 |
| JP2003500739A (en) | 2003-01-07 |
| HK1041732B (en) | 2003-06-06 |
| EP1192532B1 (en) | 2003-03-19 |
| HK1041732A1 (en) | 2002-07-19 |
| JP5520446B2 (en) | 2014-06-11 |
| WO2000072140A3 (en) | 2001-02-15 |
| CA2365572A1 (en) | 2000-11-30 |
| AU777692B2 (en) | 2004-10-28 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| JP5820339B2 (en) | Extended attributes of applications generated using 4th generation programming tools | |
| US8020173B2 (en) | Method and system for associating parameters of containers and contained objects | |
| US5896532A (en) | Objects with run-time classes and methods of making them | |
| EP1474753B1 (en) | Component model for real time system control | |
| US6275868B1 (en) | Script Engine interface for multiple languages | |
| US6064382A (en) | Object oriented apparatus and method for providing a graphical user interface for host-based software applications | |
| US6002867A (en) | Development system with methods providing visual form inheritance | |
| US5850548A (en) | System and methods for visual programming based on a high-level hierarchical data flow model | |
| US5551037A (en) | Apparatus and methods for visualizing operation of a system of processes | |
| US7890853B2 (en) | Apparatus and machine-readable medium for generating markup language representing a derived entity which extends or overrides attributes of a base entity | |
| US5818445A (en) | Method and system for creating computer-program-based applications with developer specified look and feel | |
| US6330711B1 (en) | Method and apparatus for dynamic application and maintenance of programs | |
| JP2004133892A (en) | System and method for issuing message to program | |
| JPH0713766A (en) | Object-oriented computer system and object class management method | |
| US20070136658A1 (en) | Handling events in a descriptive context | |
| Ferguson et al. | MetaMOOSE—an object-oriented framework for the construction of CASE tools | |
| EP1826669A1 (en) | Apparatus and machine-readable medium and method for generating markup language representing a derived entity which extends or overrides attributes of a base entity | |
| de Carvalho et al. | Second Generation Object-Oriented Development | |
| von Hanxleden | Extension of KIEL by Stateflow Charts | |
| Zheng | Object-oriented method for graphical user interface design in a distributed system environment | |
| Moldaschl | ooRexxTry Reengineering | |
| Wu | EMOO: Experimental MOO: A Virtual Environment Framework |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| EEER | Examination request | ||
| MKEX | Expiry |
Effective date: 20200525 |