Skip to content

tfuda/TriggerX

 
 

Folders and files

NameName
Last commit message
Last commit date

Latest commit

 

History

6 Commits
 
 
 
 
 
 

Repository files navigation

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.

About

A Light Trigger Pattern for Force.com with Event and Recursion Control

Resources

Stars

Watchers

Forks

Releases

No releases published

Packages

No packages published

Languages

  • Apex 100.0%