Using JSDOs to create mobile and web clients : JSDO overview : Asynchronous and synchronous execution : Asynchronous execution using named events
  
Asynchronous execution using named events
For all JSDO methods that execute asynchronously, the JSDO supports a set of named events to which you can subscribe event handler functions, callback functions that execute with a signature defined to receive the results for a particular named event.
These JSDO named events fire before and after each Data Object operation executes, as well as before and after the following asynchronous JSDO methods whose execution invokes these operations:
*Standard fill( ) method
*Standard saveChanges( ) method
*Asynchronously executed custom invocation methods and the standard invoke( ) method
In addition, the JSDO provides a subscribe( ) method that allows you to subscribe event handler callbacks to each of its events and provides the unsubscribe( ) and unsubscribeAll( ) methods to remove these event handler subscriptions. For more information, see Managing JSDO event subscriptions.
Therefore, the JSDO supports the following before* and after* events for each asynchronous method:
*For the standard fill( ) method:
*beforeFill (or its alias, beforeRead) — Fires before the Data Object Read operation executes. For more information, see the description of the beforeFill event.
*afterFill (or its alias, afterRead) — Fires after the Data Object Read operation completes execution. For more information, see the description of the afterFill event.
*For the standard saveChanges( ) method:
*beforeSaveChanges — Fires before the method executes any Data Object operations. For more information, see the description of the beforeSaveChanges event.
*beforeDelete — Fires before any Data Object Delete operation executes and before any record delete initiates as part of a Submit operation. For more information, see the description of the beforeDelete event.
*afterDelete — Fires after each Data Object Delete operation completes execution and after any record delete completes as part of a Submit operation. For more information, see the description of the afterDelete event.
*beforeCreate — Fires before any Data Object Create operation executes and before any record create initiates as part of a Submit operation. For more information, see the description of the beforeCreate event.
*afterCreate — Fires after each Data Object Create operation completes execution and after any record create completes as part of a Submit operation. For more information, see the description of the afterCreate event.
*beforeUpdate — Fires before any Data Object Update operation executes and before any record update initiates as part of a Submit operation. For more information, see the description of the beforeUpdate event.
*afterUpdate — Fires after each Data Object Update operation completes execution and after any record update completes as part of a Submit operation. For more information, see the description of the afterUpdate event.
*afterSaveChanges — Fires after all the Data Object operations executed by the method have completed (including a single Submit operation, if applicable). For more information, see the description of the afterSaveChanges event.
Note: These events are listed in general firing order for a single call to the saveChanges( ) method. When there are multiple changes to the same record, the order and number of changes is optimized to send the fewest number of operation requests to the server.
Note: If saveChanges( ) executes for a Data Object resource (and operation) defined to support before-image data, and an error is raised while a record change is applied to the database on the server, the record change operation also completes with an error, and with a possible value returned as the value of getErrorString( ) called on the associated record object.
*For any asynchronously executed custom invocation methods and the standard invoke( ) method:
*beforeInvoke — Fires before the specified Data Object Invoke operation executes. For more information, see the description of the beforeInvoke event.
*afterInvoke — Fires after the specified Data Object Invoke operation completes execution. For more information, see the description of the afterInvoke event.
Note: When you subscribe an event handler to an Invoke operation event, you also specify the name of the custom JSDO invocation method so the event handler can identify which Invoke operation is about to be, or has been, executed. Note also that when you execute an invocation method synchronously, these Invoke events do not fire because all synchronous Invoke operation results are available as the return value of the invocation method itself.
Note: The saveChanges( ) method can fire all of the before* and after* events for Create, Update, and Delete (CUD) operations for any number of records in JSDO memory, whether they are fired for one CUD operation per record, as part of one network request at a time, or are all fired in the context of a single network request (as part of a single Submit operation) as creates, updates, and deletes of multiple records. In other words, there is a unique event that fires before every record is created, updated, or deleted, and one that fires after every record is created, updated, or deleted, whether it is done one record at a time across the network or as part of a batch of records in a single network request. In addition, there is one beforeSaveChanges event that fires before the saveChanges( ) method initiates any record creates, updates, and deletes and one afterSaveChanges event that fires afterall of these record creates, updates, and deletes complete, whether they are executed in multiple CUD operation requests across the network or are all executed in the context of a single Submit operation request across the network.
Note: All after events always fire whether or not Data Object operations complete successfully.