![Deploy to Salesforce](https://raw.githubusercontent.com/afawcett/githubsfdeploy/master/src/main/webapp/resources/img/deploy.png)
Table of Contents
Features
_One-Line Trigger Code
_Evaluate Field Value Changes
_Dynamic Event Control
_Recursion Control
How To Use
Test Coverage
License
Execute Triggers with a single line of code
TriggerX.handleTrigger(AccountSampleHandler.class)
Often triggers contain conditional logic that checks for changed field values
if (record.CloseDate != recordOld.CloseDate
|| record.OwnerId != recordOld.CloseDate
|| record.StageName != recordOld.StageName
|| record.Type != recordOld.Type){
// logic executed when condition is true
}
. Using the hasChangedFields and getChangedFields methods you just pass in a list of fields (String or sObjectField) for which changes should be evaluated
// use string field names
String[] stringFieldZ = new String[]{'StageName','CloseDate','OwnerId','Type'};
if (TriggerX.hasChangedFields(stringFieldZ,record,recordOld)){
// logic executed when condition is true
}
// or sObjectFields
sObjectField[] fieldZ = new sObjectField[]{Opportunity.StageName, Opportunity.CloseDate, Opportunity.OwnerId, Opportunity.Type};
for (sObjectField field:TriggerX.getChangedFields(fieldZ,record,recordOld)){
// process field
}
Turn execution of events within the runtime context on and off. Use for instance when you perform operations that cause updates on multiple hierachy levels of the same ObjectType see also Recursion Control
control single events
TriggerX.disable(AccountSampleHandler.class,TriggerX.EventType.AFTER_UPDATE)
TriggerX.enable(AccountSampleHandler.class,TriggerX.EventType.AFTER_UPDATE)
control multiple events
TriggerX.disable(AccountSampleHandler.class
,new TriggerX.EventType[]{
TriggerX.EventType.AFTER_INSERT
, TriggerX.EventType.BEFORE_UPDATE
, TriggerX.EventType.AFTER_UPDATE})
TriggerX.enable(AccountSampleHandler.class
,new TriggerX.EventType[]{
TriggerX.EventType.BEFORE_UPDATE
, TriggerX.EventType.AFTER_UPDATE})
control entire trigger via code
TriggerX.disable(AccountSampleHandler.class)
TriggerX.enable(AccountSampleHandler.class)
control trigger via custom setting
With the custom setting TRIGGER_CONTROL you can control the execution of your trigger via configuration, which is especially usefull when performing data migration and massive batchjobs. The following custom setting for the AccountSampleHandler.class
TRIGGER_CONTROL__c {
Name = 'AccountSampleHandler'
, AFTER_INSERT__c = true
, AFTER_UPDATE__c = false
, AFTER_DELETE__c = false
, AFTER_UNDELETE__c = true
, BEFORE_INSERT__c = false
, BEFORE_UPDATE__c = false
, BEFORE_DELETE__c = false}
will prevent the execution of all BEFORE events as well as AFTER UPDATE and AFTER DELETE events for AccountSampleHandler.class. If no TRIGGER_CONTROL__c record exists, all events are considered as enabled!
The built-in recursion control allows you to keep track of updated records within the current runtime context and filter on those records which have already been processed. Use for instance for updates on multiple hierachy levels of the same ObjectType or for recursive updates.
// add all records in the current update context to the updatedIds and
TriggerX.addUpdatedIds(triggerOldMap.keySet());
// and use this to return only records which havent been processed before
#getNonRecursiveUpdates()
Handler class
Create a Handler class that extends TriggerX, per Custom Object. Overwrite those methods you actually want to handle. Keep in mind, that you have to cast the record variables to the concrete sObjectType
public class AccountSampleHandler extends TriggerX {
// handle after update
public override void onBeforeInsert(){
for (Account record:(Account[])records){
// BEFORE INSERT LOGIC
}
}
// handle after update
public override void onAfterUpdate(Map<Id,sObject> triggerOldMap){
// just process Account records that haven't been updated in the same context
for (Account record:(Account[])getNonRecursiveUpdates()){
// AFTER UPDATE LOGIC
}
// prevent recursion
TriggerX.addUpdatedIds(triggerOldMap.keySet());
}
}
Create then a Trigger for your Custom Object and call TriggerX.handleTrigger with the Type of the handler class you just created
trigger AccountSample on Account (before insert, after update){
TriggerX.handleTrigger(AccountSampleHandler.class)
}
TriggerX.cls has a 100% test coverage. AccountSampleHandler.cls and AccountSample.trigger might have a lower coverage, depending on required fields and validation rules on Account and Contact.
Redistribution and use in source and binary forms, with or without modification, are permitted.