Skip to content

DS Archive Support Website

Sections
Personal tools
You are here: Home » Product Manuals DS 3.x » DataSplice 3.1 Basic Administration » Event Handling Basics

Event Handling Basics

Events allow fine-tuned control over how the DataSplice clients behave when the user performs specific actions.
The Event Chain Settings section in the view editor contains the various screens needed to control the event settings in DataSplice. The Event Bindings section allows entries to be added for the events that need customization in the view. This section is also available when editing internal role objects, which is used to define event mappings that do not require a view to be selected (LogOut, OfflineSync, Keypress).

Event Bindings

Events are fired based on application events, actions performed by the user, and custom conditions handled by loaded plug-ins.

When an event is fired, DataSplice will execute a chain of actions as specified by the configuration to process the event. By default the chain consists of a single action that performs the basic function for the event. The Administration Client can be used to add additional actions when needed to specify custom business logic. These can be set up in two ways:

  • Before and After the default action, with the additional actions handling validation and post conditions associated with the event.
  • Instead of the default action, such that the other actions in the chain completely provide the functionality needed for the event.

For each event the steps taken by the Default Action are described below, since they are specific to the actual event in question. Additional actions before and after the default will be processed with that context in mind, and if the default action is removed from the chain or skipped because of the condition those steps will not be performed.

This may or may not make sense depending on the configuration. For instance, the default action for the update, insert, and delete events is very rarely called - typically the view will be configured to pass the modifications off to a separate business rule processing layer. However not calling the default action for the query events rarely makes sense because this will always result in an empty set of data.

Event Qualifiers

Certain events have an additional qualifier that further specifies when the specified actions should be fired. For instance, the qualifier for the Keypress event is the sequence that should fire the event, and the qualifier of the VerifyField event is the name of the field being modified.

If the event has no qualifier it can only have a single binding, and qualified events can have multiple bindings as long as the qualifier is different.

The qualifier for these events can be specified in a couple of ways:

  • The explicit value to match
  • A comma separated list to match multiple values
  • A pattern (/regex/) to match values based on a regular expression

In cases where multiple bindings match a particular qualifier the applications will execute the most specific match.

Server-Side Events

The following events are processed by the server in order to integrate with the target data sources that are mapped to various views.

Event Name
Qualifier Details
ServerQuery none Handles data queries on the server to request client queries from the associated backend data source. This is fired both when the user explicitly requests data, and when other actions (dynamic lists, query expressions) attempt to access data.

Default Action: Sends query to server data source to be processed.
UpdateRecord none Commits records modified by the user to the backend data source. Note that this event is not fired when a user modifies a record on the client application, but rather when the modification is committed to the server by the user.

Default Action: Requests server data source to update record. For instance, the ADO.NET data source will execute an UPDATE SQL statement to modify the data.
InsertRecord none Commits records that have been created on the client to the backend data source. Similar to the UpdateRecord event, this is fired when changes are committed to the server and not when records are created on the client.

Default Action: Requests server data source to insert the new record. For instance, the ADO.NET data source will execute an INSERT SQL statement to create a new record in the associated table.
DeleteRecord none Commits records that have been marked for deletion to the backend data source. Similar to the UpdateRecord event, this is fired when changes are committed to the server and not when records are marked for deletion on the client.

Default Action: Requests the server data source to delete the specified record. For instance, the ADO.NET data source will execute a DELETE SQL statement to delete the selected record.

Client-Side Events

Event Name
Qualifier Details
ClientQuery
none
Handles offline queries on the client to fetch locally stored data that matches a query.

Default Action: Executes the query against the locally stored offline data.
CreateRecord
none Fired when the user creates a new record within a view, either by clicking the Create Record button, or by accessing an action that creates a new local record.

Default Action: Creates the new record and applies any field defaults.
MarkForDelete
none Handles marking records to be deleted on the client.

Default Action: Marks the record to be deleted, or in the case of inserted records it removes them from the data store.
VerifyRecord
none Fired when the user attempts to leave the currently selected record, either by selecting another record or moving to a different section of the client application. This allows the Remote Client to validate the data provided by the user and ensure that correct data has been entered.

Default Action: Does nothing, though if this event fails the user is prevented from leaving the record.
VerifyField
Field Name
Processes new values for fields, either when explicitly edited by the user or when modified by other events and actions. This is typically used to validate the supplied value, and cascade changes to depended fields where needed.

Default Action: Applies the new value to the record.
PerformAction
Action Name
Executes navigation actions to display related data and perform other configured actions within a view. Navigation Actions are covered in the Display Settings section of this document.

Default Action: Performs the task specified by the associated action.
DefaultCommand
Current Display Mode
(filter/grid/record)
Handles the default action for the view when the user presses the Enter key. This is used to reduce the amount of screen taps/mouse clicks needed to navigate through the configured views. For instance, this is often used to automatically display results for the current query after filling out values in the query editor.

Default Action: Displays the menu in the navigation bar.
Keypress
Keypress Sequence
Handles keyboard input typed by the user. The qualifier can be a single key ( F1, Esc, Enter ) or a control sequence formatted like alt+<char>, ctrl+<char>, win+<char>.

Default Action: Passes the character on to the selected control.
LogOut
none
Commits any pending modifications to the server and releases the current session. This is typically used to take actions before logging out.

Default Action: Performs the log out operation with the server.
OfflineSync
none
Synchronizes data on the handheld by committing pending changes and updating the data available to the user. Overriding this can be used to prompt the user for information prior to a sync, or perform other data cleanup operations during the process.

Default Action: Perfoms the offline synchronization operation.

Plug-in Events

Plug-in modules are capable of registering an firing events. The available events can change depending on plug-ins that are installed.

Event Name
Disposition
Qualifier Details
BarcodeScan
Client
Scanned Data
Called when the user successfully scans a bar code label. The scanned input is passed as the event qualifier, which allows bindings to use patterns to match the details of what the user scanned.

As mentioned in the client configuration section, the desktop version of the scanner plug-in can be enabled to fire this event when a particular keypress sequence is typed, which allows the event processing the be tested on machines that don't have a scanner. This will display a prompt for the data that should be simulated in the scan event, and then fires the processing in the client.

Default Action: Replaces the text in the current edit control with the scanned input.

Miscellaneous Events

Event Name
Qualifier Details
Custom
Unique Event Identifier
This event is never directly fired by the system, but can be used by administrators to create sets of functionality that are referenced by different elements in the configuration. These can be called from other events or navigation actions, and essentially create subroutines of functionality within a view.

Default Action: Does nothing

 

 

Last modified 2009-10-13 01:12 PM
 

Powered by Plone

This site conforms to the following standards: