Note: Nintex Apps data centers are located in West US and Australia (AUS). In-region processing of Nintex Apps data is only available in these regions.
All code samples below refer to the skuid object.
In the v2 API, this object is not directly accessible when working within a browser console—or when referring to another Nintex Apps page runtime.
If you are experiencing issues, use the skuid.runtime API to target the appropriate page context.
skuid.events
skuid.events.publish(event,data)
Publishes an Event
Arguments: |
---|
|
skuid.events.subscribe(event,callback)
Establishes an Event subscription
Arguments: | Returns object: |
---|---|
|
A subscription "handle" which can be used to unsubscribe |
Note: If using the Publish event action, this API can only subscribe to events published to All active pages.
skuid.events.subscribeOnce(event,callback)
Subscribe for a single event --- after it happens once, unsubscribe
Arguments: |
---|
|
skuid.events.unsubscribe(subscription)
Removes a particular event subscription, such that the registered callback will no longer be invoked when the associated event is published.
Arguments: |
---|
|
Nintex Apps Events Reference
The following is a list of the standard Events published by Nintex Apps. For each Event, two pieces of information are provided:
- The situation in which Nintex Apps publishes the event
- The additional data that Nintex Apps provides to event subscribers
Models
Rows
Property | Type | Required | Description |
---|---|---|---|
skuid.events.models.cancelled | object | No |
Published: at the end of a call to model.cancel() or skuid.model.cancel([modelsArray]) call, after all changes have been thrown out of the models and any original data has been restored Data:
|
skuid.events.models.loaded | object | No |
Published: at the end of a successful call to model.updateData() or skuid.model.updateData([modelsArray]) call, after the models have been updated to include the new data retrieved from the server at the end of a successful call to model.load() or skuid.model.load([modelsArray]) call, after the models have been updated to include the new data retrieved from the server Data:
|
skuid.events.models.saveInitiated | object | No |
Published: while a call to model.save() or skuid.model.save([modelsArray]) is still in progress and before any validation has been performed Data:
|
skuid.events.models.saved | array of Message objects | No |
Published: after a call to model.save() or skuid.model.save([modelsArray]) has finished, and—if the save was successful—after the models have been adjusted to reflect the successful changes, whether inserts, updates, or deletes, to the models involved Note: Check the totalsuccess property to confirm that the save operation was successful. Data:
|
skuid.events.models.saveHandled | array of Message objects | No |
Published: at the end of any call to model.save() or skuid.model.save([modelsArray]) call, regardless of whether the save call succeeded or failed Data:
|
skuid.events.row.created | string | No |
Published: at the end of a call to model.createRow() Data:
|
skuid.events.row.updated | string | No |
Published: at the end of a call to model.updateRow() or model.updateRows() --- for calls to updateRows(), row.updated will be published separately for each row Data:
|
skuid.events.row.deleted | string | No |
Published: at the end of a call to model.deleteRow() Data:
|
skuid.events.row.undeleted | string | No |
Published: at the end of a call to model.undeleteRow() Data:
|
Conditions
In addition to being available as an initiating event for model actions within action flows, model condition changes and their respective JavaScript functions now fire JavaScript events. These events and their payloads contain useful data for JavaScript snippets and custom components.
When the setCondition() method—which both sets a value for a condition and then activates it for any future re-queries—is called, the condition.valueChanged event is published, which contains the following data as the event payload:
{
event: "condition.valueChanged",
conditionName: <Condition Name>,
modelId: <Model Id>,
newValue: The new "value" property on the condition, unless it is a multi-value condition, then this would be the new "values" property
oldValue: The old "value" property on the condition, unless it is a multi-value condition, then this would be the old "values" property
}
When the activateCondition() method—used to simply activate toggle style conditions—is called, the condition.activated event is published, which contains the following data as the event payload:
{
event: "condition.activated",
conditionName: <Condition Name>,
modelId: <Model Id>
}
When the deactivateCondition() method is called—such as when the Deactivate Filterable Conditions action occurs, the condition.deactivated event is published, which contains the following data as the event payload:
{
event: "condition.deactivated",
conditionName: <Condition Name>,
modelId: <Model Id>
}
Examples
Subscribing to a Nintex Apps Model event
One common use case for the Nintex Apps Publish / Subscribe API, with standard events, would be as a more generic alternative to using skuid.ui.Editor and skuid.ui.Field to listen for structured changes to particular Nintex Apps models and rows.
For instance, if you wanted to perform certain logic any time that rows were updated in a particular subset of Models, you could do it like this:
skuid.events.subscribe('row.updated',function(updateResult){
if ((updateResult.modelId === 'OpportunityData') && (updateResult.rowId===someRecordId)) {
// Run my logic
}
});
Or if you wanted to automatically requery a certain set of models whenever other models were saved, you could do this:
skuid.events.subscribe('models.saved',function(saveResult){
if (('NewOpportunity' in saveResult.models)&&(saveResult.totalsuccess)) {
skuid.model.updateData([skuid.model.getModel('AllOpportunities')];
}
});
To unsubscribe from the event, keep a reference to the subscription returned when you subscribed, and then call unsubscribe():
var subscription = skuid.events.subscribe('row.updated', function() { ... });
skuid.events.unsubscribe(subscription);
Publishing / subscribing to a custom event
Another common use case for the Nintex Apps Events API is to publish and subscribe to custom events relevant to your application. For instance, you may have a custom visualization component that subscribes to the "acme.page.resize" event. Because your component subscribes to this custom event, this event can now be easily invoked by other areas of the application, either via JavaScript or via the Nintex Apps Action Framework's "Publish Event" action.
Example Component code that subscribes to the event:
skuid.componentType.register('acme__chart',function(element,xmlDef,component){
// Subscribe to a custom Page Resize event
skuid.events.subscribe('acme.page.resize',function(config,eventDetails){
if (eventDetails && eventDetails.direction==='vertical') {
// Adjust for vertical resize
}
if (config && config.doSomething) {
// Do something special
}
}
});
And then somewhere else in the application that performs "page resize" functionality would publish the event, causing the chart's subscription to be invoked:
var config = {
doSomething: true
};
var eventDetails = {
direction: 'vertical'
};
skuid.events.publish('acme.page.resize',[config,eventDetails]);