Event handling with action instances for event-driven software application

Methods, computer systems and apparatus, including computer program products, for handling events in an event-driven software application. An event request specifying an event and values for one or more event parameters is received in a system event handler. The system event handler identifies an action associated with the specified event. The action specifies a required set of parameters and an event handling function specifying one or more operations that can be performed on data. The system event handler generates an instance of the identified action by mapping the event parameter values to the required set of parameters. The event handling function is called in an application event handler with the generated instance of the identified action to invoke application code.

BACKGROUND

The present invention relates to data processing by digital computer, and more particularly to event handling.

In the model-view-controller (MVC) design pattern used for developing software applications, the model represents the core of an application. The model can have multiple views, where each view displays information about the model to a user. A controller of the model receives events—for example, from a user through a user interface—to manipulate the model. The model and the controller typically include application code. When changes occur in the model, the model updates all of its views. Data binding is used for decoupling controller and view with regards to data flow. For example, a table view can be defined to display data of a corresponding table that is stored in the model or controller. The table is used as data source for the table view (data binding). The table view can be replaced by a different view, such as a link list, that binds against the same table. In this case the new view displays the table data without changing anything in the controller or the model. When the table view initiates an event (e.g., “onClick”), the event is processed by the controller. Typically, the controller includes an event handler that expects a specific signature (e.g., a specific list of parameters), such as “onClick(tableViewCell)”, for a given event. However, when the table view is replaced by the link list view, the signature of the event is likely to change. For example, a different parameter may be passed to controller (e.g., “onClick(LinkListltem)”). Without further modification the controller may not be able to process the event that is initiated by the link list view of the event handler.

SUMMARY OF THE INVENTION

The present invention provides methods and apparatus, including computer program products, for decoupling system events from application events handling in an event-driven software application. In general, in one aspect, the invention features methods and apparatus, including computer program products, implementing techniques for event handling. The techniques include receiving an event request specifying an event and values for one or more event parameters; identifying an action associated with the specified event, the action specifying a required set of parameters and an event handling function specifying one or more operations that can be performed on data; generating an instance of the identified action by mapping the event parameter values to the required set of parameters; and calling the event handling function with the generated instance of the identified action.

The invention can be implemented to provide one or more of the following features. The event request can be a request for an event initiated in response to user input. The user input can be received in an interface defined in a view of a model-view-controller design pattern. The specified event can include information identifying one or more manipulations to be performed on data in a model associated with the view. The event handling function can specify one or more operations required to carry out the identified manipulations. The action can be defined in a controller associated with the view. The action can be associated in the view with the specified event. The controller can implement an event handler associated with the action. The event handler can include an implementation of the event handling function. The event handling function can call application code in the model or the controller. The application code can implement the specified operations.

Receiving an event request can include receiving an event request in a first event handler and extracting a representation of the event from the request. The techniques can include determining whether the generated instance of the identified action is a valid instance of the identified action. The event handling function can be called only if the generated instance of the identified action is determined to be valid. The techniques can include determining whether the specified action is enabled. The event handling function can be called only if the action is determined to be enabled. The specified action can include an enabled attribute having a value indicating whether the action is enabled or disabled. Determining whether the specified action is enabled can include accessing the value for the enabled attribute.

In general, in another aspect, the invention features a computer system for event handling. The system includes a system event handler operable to perform an analysis to determine whether a system event received by the system event handler triggers an application event; and an application event handler operable to call application code if the application event is triggered and invokes the application event handler.

The invention can be implemented to provide one or more of the following features. The system event handler, when performing the analysis, can determine whether the system event includes a valid representation of an action associated with the application event. The system event handler, when performing the analysis, can determine whether the action is enabled. The action can be defined in a controller of a model. The controller can implement an application event handler associated with the action. The application event handler can implement an event handling function to call the application code. The system can include a phase handler operable to control a plurality of phases of the computer system. The plurality of phases can include a request handling phase, a system event handling phase, a data validation and transport phase and an application event handling phase. The phase handler can receive a request in the request handling phase. The phase handler can extract the system event from the request. After extracting the system event from the request, the phase handler can start the system event handling phase. After receiving a valid representation of an action, the phase handler can start the data validation and transport phase. The phase handler can call validation services during the data validation and transport phase to convert non-typed values of the request into typed values and to validate the typed values. The phase handler can start the application event handling phase after successful completion of the data validation and transport phase by initiating the application event associated with the action.

In general, in another aspect, the invention features a computer system for event handling. The system includes a model; a view operable to present the model and initiate a system event, the view being further operable to associate the system event with an action; and a controller operable to manipulate the model in response to the system event, the controller being operable to provide the action and to call application code through an event handling function associated with the action.

The invention can be implemented to provide one or more of the following features. The system event can be received by a system event handler that returns a representation of the action to a framework. In response to receiving the representation of the action, the framework can invoke an application event handler that implements the event handling function.

In general, in still another aspect, the invention features methods and apparatus, including computer program products, implementing event handling techniques. The techniques include providing a model, a view operable to present the model and initiate a system event, and a controller operable to manipulate the model in response to the system event; providing an action in the controller; associating the system event with the action; and calling application code through an event handling function associated with the action to manipulate the model in response to the system event.

In general, in another aspect, the invention features methods and apparatus, including computer program products, implementing event handling techniques. The techniques include performing an analysis of a system event in a system event handler to determine whether the system event triggers an application event; initiating the application event in response to the analysis of the system event; and processing the application event by an application event handler to call application code.

The invention can be implemented to provide one or more of the following features. The techniques can include receiving a request in a phase handler, and extracting the system event from the request. The techniques can include returning from the system event handler to the phase handler a valid representation of an action associated with the system event. The application event can be associated with the action. The phase handler can initiate the application event if the action is enabled.

The invention can be implemented to realize one or more of the following advantages. Decoupling system events from the corresponding application events by using event binding separates the system event handling level from the application event handling level. The system event handler need not implement application logic for event handling, but simply invokes the corresponding application event handler. This allows an application developer (or user) to replace views in an extended MVC design pattern without modifying the corresponding controller or model.

The details of one or more implementations of the invention are set forth in the accompanying drawings and the description below. Other features and advantages of the invention will become apparent from the description, the drawings, and the claims.

DETAILED DESCRIPTION

As shown inFIG. 1, an exemplary computer system900in accordance with the invention stores a model301, a view303of the model301, and a corresponding controller302. The model301and the controller302can include application code200that defines an application. The view303presents data of the model301and/or controller302to the user. The model301can have multiple views that can be represented to the user as different presentations of the application (model301/controller302). When the user interacts with the computer system900through a graphical user interface that includes a presentation of the model301/controller302, the user10uses the controller302to manipulate the model301, which updates its views (e.g., view303) to reflect the results of the user's actions.

The computer system900includes a system event handler100-1to receive and process system events that result, for example, from user interactions. The system event handler100-1can be implemented as a method of a specific controller class. For example, if the user10selects a specific user interface (UI) element, such as an OK button, displayed in one of the views of the model301, and if selection of the UI element initiates a system event (e.g., “onClick”), the system event handler100-1receives the system event. Additional examples of UI elements include links, menu items, toolbars or leaves of a tree. Additional examples of system events include scroll events or help request events. Not every system event triggers an application event. For example, system events that are initiated by scrolling a table can be handled by the system event handler100-1without an application.

After the system event handler100-1receives a system event, it analyzes the system event to determine whether the system event triggers an application event, and provides the analysis result to a framework in the computer system900. Examples of application events include “CheckAvailibility”, “CheckValidBusinessPartner” and “SaveOrder”. If the system event handler determines that the system event triggers an application event, the framework invokes a corresponding application event handler100-2by initiating an application event that corresponds to the system event. In one implementation, the application event handler100-2is a method that is implemented in the controller302. In other implementations, the application event handler100-2can be located in any controller. The application event handler100-2calls application code200that is associated with the application event and that is implemented by the model301(as shown in the example ofFIG. 1) or the controller302.

Thus, the system event (e.g. “onClick”) that is initiated by a particular UI element is decoupled from the corresponding application event (e.g., “SaveOrder”). In other words, the system event handler100-1does not need to implement application logic for event handling, but simply invokes the corresponding application event handler100-2.

FIG. 2illustrates one example of a visualization of a view303that is presented to the user10as a graphical user interface (GUI)955of an application. In this example, the user is a sales person of a specific sales organization SO1, and uses the GUI955to create new customers in a customer relationship management (CRM) system of the sales organization SO1. GUI955includes four UI elements: a title955-1(CREATE NEW CUSTOMER) for displaying the title of the application; a first input field955-2(CUSTOMER NUMBER) for entering a customer number; a second input field955-3(CUSTOMER NAME) for entering a customer name; and a SAVE button955-4for saving the values of the input fields (e.g., in a corresponding portion of a database). In the example shown inFIG. 2, the user has entered CUSTOMER NUMBER “123” and CUSTOMER NAME “SMITH”, and sends a corresponding request to the computer system900by selecting the SAVE button.

FIG. 3illustrates a mapping scheme for handling events initiated in view303illustrated inFIG. 2. The controller302defines actions (e.g., ACTION A, ACTION B) that implement application events. A system event (e.g., “onClick”, “onSelect”) that can be initiated by a UI element of the view303and that triggers an application event is associated with a corresponding action of the controller.

Actions can have one or more attributes, such as “enabled” to indicate if the action is enabled, “text” to define a text of the action to be displayed by the view, and “function” to reference an event handling function (e.g., F1, F2) that is implemented in a corresponding application event handler. Each action A, B that is defined in the controller302is associated with a corresponding application event handler100-2,100-3, respectively, that implements an associated event handling function F1, F2. Actions also include information about the signature of (e.g., parameters required by) the associated event handling function. Table 1 illustrates a simplified example of a declaration of action A (FIG. 2) in the controller302.

An action can be instantiated from a corresponding action class of the controller302. The “enabled” attribute can be set by an application developer at design time when building the application. The declaration of an action can also include further attributes, such as sound attributes, that can be used as additional guidance for disabled users for navigating in the GUI.

In one implementation, the view303has an associated event-action table150. The event-action table150includes a SYSTEM EVENT column to list system events that can be initiated by specific UI elements of the view303, such as the SAVE button (e.g., “onClick_Button_SAVE”). The ACTION NAME column specifies an action name (e.g., “save”, “bbb”) for the action to which each system event that triggers an application event is assigned. The event-action table150can include further columns to reflect the signature of (e.g., parameters required by) an action. For example, an action A for saving a new customer can have parameters such as the customer number, the customer name, and the sales organization serving the new customer. The view303also defines the mapping of system event parameters to parameters of the corresponding action. Each system event is unique in the event-action table150with regards to the view303.

A row of the event-action table150that specifies an action name for a system event is mapped to a corresponding row in an action table160of the controller. The mappings are illustrated by arrows pointing from rows of the event-action table150to the action table160. The ACTION NAME column of the action table160includes the action names (e.g., “save”, “bbb”) of the actions that are defined by the controller302. In the example, tables150,160are mapped according to the action name. Alternatively, other information can be used for the mapping. The mapping can also be defined dynamically through program code that is evaluated at runtime. The ACTION column of the action table160includes a reference to an action (e.g., A, B). The references (both from the action table160to the corresponding action, and from the action to its associated event handling function) are illustrated by arrows from the rows of the action table to the corresponding action and further to the event handling functions in the associated application event handlers.

Because system events are bound to actions—that is, because view's system events (and their parameters) are mapped to the controller's actions (and their parameters)—a view303can be replaced with another view of the model without requiring modification of the controller302and still result in a working eventing model. The controller302defines the actions that can be used by views of the model301, and each view maps its system events to these actions. To ensure unambiguous mapping rules, the name of each action is unique within the scope of a controller. The mapping functions of the event-action table150and the action table160can be implemented by alternative means, such as structured documents (e.g., XML documents) or equivalent data structures with appropriate pointers.

FIG. 4illustrates one implementation of a computer program product (CPP)100running on the computer system900and including the system event handler100-1and the application event handler100-2. CPP100includes a phase handler100-9to chronologically control a plurality of phases of the computer system900, including a request handling phase, a system event handling phase, a data validation and transport phase and an application event handling phase. The phase handler100-9can be implemented as a part of the framework.

When the user interacts with the computer system and generates a request REQ, for example, by using a client computer that presents the view303to the user (e.g., through GUI955), the phase handler100-9receives the request in the request handling phase. The request can also originate from a second computer system that communicates with the computer system over a network, such as a local area network (LAN), a wide area network (WAN) or the Internet. The view303can be presented to the user on an output device (e.g., a monitor) of the client computer. The phase handler100-9then extracts the system event SE from the request REQ.

The phase handler100-9starts the system event handling phase and sends the system event SE to the system event handler100-1. The system event handler100-1performs an analysis to determine if the system event SE triggers an application event AE. For example, the system event handler100-1determines whether the system event SE is associated with (e.g., assigned to) a corresponding action and, if so, determines with which action (e.g., action A) it is associated. The system event handler100-1can also determine if the action A is enabled (e.g., by verifying a corresponding “enabled” attribute from the declaration of the action A in the controller302). The system event handler100-1then returns the result110of the analysis to the phase handler100-9. The result110includes the representation of the action A, and can also include, for example, the value of the “enabled” attribute. If the value of the “enabled” attribute indicates that the action A is disabled, the phase handler100-9can respond to the request REQ with a corresponding message. Otherwise, once the phase handler100-9receives the valid representation of the action A, it starts the data validation and transport phase.

During the validation the phase handler can call validation services of the framework to convert non-typed data (e.g., raw string representation of data) of the original request REQ into typed data and to validate the typed data according to predefined validation rules. The predefined validation rules can be stored in a memory portion of the computer system900, for example, in the form of a data dictionary or a rule data base. During the data transfer, data of the view303can be transported to the model301or the controller302depending on predefined data binding rules.

If any error occurs during the data validation and transport phase, the phase handler100-9can respond to the original request REQ by, for example, posting an error message or prompting the user to correct a corresponding user input. Referring back to the example ofFIG. 2, if the user enters a customer number999and the range of customer numbers for the sales organization SO1is limited to the range from 001 to 300, then a validation service checking the validity of the customer number can generate an error message and the phase handler100-9can prompt the user to re-enter the customer number in GUI955. If the data validation and transport phase is successfully completed, the phase handler100-9starts the application event handling phase.

The application event AE is constructed from data of the system event SE, the corresponding action (including its signature), and the mapping of system event parameters to action parameters. The application event AE includes typed data instead of the originally non-typed data of the system event SE and, in general, has a different signature. The appropriate application event handler100-2is identified through the action A corresponding to the application event AE. The application event handler100-2then calls (CALLS) application code200by processing the event handling function F1(cf.FIG. 2) that is implemented in the application event handler100-2. The application code200can be implemented within the model301, as it is in the example ofFIG. 4, or within the controller302. In the latter case, the application event handler100-2calls the application code of the controller302instead of the model301.

FIG. 5illustrates a method400that can be used to implement event handling in an extended MVC design pattern. The method begins when the computer system900receives a request REQ (step410) that can, for example, result from a user interaction or that can be raised by a further computer system. Referring to the example ofFIG. 2, if the request REQ results from the user interaction with SAVE button955-4of the view303, the request REQ can include the following data in a string format:

The phase handler100-9extracts the system event (e.g., “onClick_Button_SAVE”) from the request (step420). The phase handler100-9can extract the system event from the request using conventions defined by a communication protocol, such as the hypertext transfer protocol (HTTP). The phase handler100-9sends the system event to the system event handler100-1. In one implementation, steps410and420are performed during the request handling phase, described above.

The system event handler100-1analyzes the system event to determine whether the system event (e.g., “onClick_Button_SAVE”) includes a valid representation of an action (step430). For example, in the example ofFIGS. 2-3, the system event handler100-1accesses the event-action table150and finds the action name “save” assigned to the system event “onClick_Button_SAVE”. The system event handler100-1retrieves from the view303information describing how parameters of the system event map to corresponding parameters of the action. The system event handler100-1can retrieve from the controller102information about the action's signature (e.g., parameters that the particular action requires). Thus, for example, the system event handler100-1learns from the controller302that action A, referenced by action name “save”, requires the parameters SALESORG, CUSTNR and CUSTNAME. The system event handler100-1can also learn from the controller302whether the identified action has an “enabled” attribute and read the value (e.g., “true” or “false”) of this attribute. A simplified example of one implementation of a system event handler100-1is illustrated in Table 2.

The view303can define the parameter mapping in the event-action table150or an equivalent mapping data structure. For example, in the example ofFIG. 2, the view input field CUSTOMER NUMBER can be mapped to the action parameter CUSTNR, and the view input field CUSTOMER NAME can be mapped to the action parameter CUSTNAME. The parameter SALES ORGANIZATION can be stored in the view303as a constant value SO1if the view303is intended for use only by sales people of sales organization SO1. In that case, the mapping simply assigns the constant value SO1to the action parameter SALESORG. Referring to Table 2 in the context of the example ofFIGS. 2-3, event.name equals “onClick_Button_SAVE”; action.parameters is a collection of the parameters of the action A (“save”), including CUSTNR, CUSTNAME, and SALESORG. For each parameter of the action A, the parameter value is set by the view303to the values entered in the view input fields CUSTOMER NUMBER, CUSTOMER NAME and to the constant value “SO1”, respectively.

In one implementation, a UI element of a view can be generated at runtime. In such implementations, an action can be dynamically assigned to the UI element. Table 3 illustrates an example of a function OnOutputProcessing that can be used to assign an action “set_options” to a button “OPTIONS” that is generated at runtime.

If the system event handler determines that the system event includes a representation of a valid action A for the system event, the system event handler returns the identified valid action A to the phase handler100-9as part of the result110of the analysis (step440). The returned result can also include information about the action's signature, and the parameter mapping information. Steps430and440can be performed during the system event handling phase, described above. The result110can also include the value of the “enabled” attribute of the action A. In one implementation, the start of the data validation and transport phase can further depend on the value of the “enabled” attribute. If the action A is disabled, the phase handler100-9can send a corresponding response to the user. Otherwise, the data validation and transport phase is started.

The phase handler validates the data and transfers the validated data from the view303to the model301or the controller302(step450). To validate the data, the phase handler calls validation services that transform non-typed (string) values of the original request REQ into typed values. For example, “CUSTOMER NUMBER”=“123” is transformed into CUSTNR=123, where CUSTNR has a type integer (3). The validation services can then validate the typed values against predefined validation rules. For example, a validation rule can indicate that users of the sales organization S01are only allowed to create customer numbers in the range from 001 to 300. If this condition is not fulfilled, the phase handler can send a corresponding response (e.g., error message) to the user. Once the typed values are validated (e.g., no errors occurred during the validation), the data are transferred from the view303to the corresponding data sources (e.g., a database table) of the model301or the controller302.

The phase handler100-9next initiates an application event (step460). The phase handler100-9uses the information about the action A, its signature, attributes and the typed values to construct the application event that invokes the application event handler100-2that corresponds to the action A. In one implementation, steps450and460are performed during the data validation and transport phase, described above.

The application event handler100-2processes the application event (step470). For example, if the action information in the application event includes a reference to the corresponding event handling function F1(e.g., F1=“save_new_customer”), the application event handler100-2process the application event by executing the event handling function F1that is referenced in the application event. The event handling function F1implements application specific code that, when executed, calls the application code200(e.g., of the model301) in response to the application event. A simplified example of one implementation of an application event handler100-2in the context of the example ofFIG. 2is described in Table 4.

In the example of Table 4, the application specific coding that corresponds to event handling function F1includes instructions to access an application database (DataBase) and to store a record for the new customer in the application database. Step470can be performed during the application event handling phase, discussed above.

The invention has been described in terms of particular embodiments. Other embodiments are within the scope of the following claims. For example, the steps of the invention can be performed in a different order and still achieve desirable results.

Although the invention is described in the context of a user interacting with a graphical user interface, the described methods, computer programs and systems can also be implemented to enable interaction with other user interfaces, such as voice driven user interfaces. In a voice driven user interface, for example, the view can include UI elements defined by specific sounds or words, which can be useful for users that are blind or have other disabilities.

The methods and computer program products are described in the context of pseudo code examples using an XML-like notation. However, corresponding code can be implemented in any appropriate programming language, such as Java or C++.

It can be convenient for applications to share standard actions such as “save”, “mail to” or “print” to reuse the same action definition multiple times. Such standard actions can be created and stored in a public or private repository, such that an application programmer can easily reuse an action and bind the action to any UI element in any view. A controller definition can provide for the use of a standard action by, for example, defining a value for a specific repository attribute.