This commit fixes issue 86

[Autobat]

Simple interface to be able to disable/enable trigger events from running.

This common code is repeated many times in many instances of SFDC. Where programatically we wish to prevent one, many or all trigger events firing for a domain. There are many reasons why this is required and this allows the developer to easily control which events are fired by using:

fflib_SObjectDomain.getTriggerEvent(Accounts.class).enableAll();  // this is the default behaviour

...
// mass adjustment
.disableAll();
.disableAllBefore();
.enableAllAfter();
.disableAllAfter();

// singular
.enableBeforeInsert();
.disableBeforeInsert();

... etc

Currently the class is called EventTrigger which i'm not sold on, if anyone can think of a better name I am happy to change.

Cheers

[Autobat]

let me know if this requires any tweaking or modifications. I have a whole lot of flying and waiting in airports over the coming weeks!

[afawcett]

Ha about to start a bit of the same myself. WIll take a look, thanks! 👍

[afawcett]

Great contribution! Not sure if you have a blog or not, wondered if you wanted to write a short blog on why you contributed this, your motivations and some example code? BTW, love the use of the fluent API style! ;-)

[Autobat]

I don't have a blog but great idea. I can write a piece and we can find someone to host as a guest entry.

Chris Mail

On 19 Mar 2016, at 02:10, Andrew Fawcett notifications@github.com wrote:

Great contribution! Not sure if you have a blog or not, wondered if you wanted to write a short blog on why you contributed this, your motivations and some example code? BTW, love the use of the fluent API style! ;-)

—
You are receiving this because you authored the thread.
Reply to this email directly or view it on GitHub

[Autobat]

@afawcett is this what you're looking for?

How to put the safety on.

Being an architect in a professional services organisation is a funny game. Each project is either a shiny new Salesforce instance without a fingerprint on it or an unknown vault of code and configuration that we must navigate through.

I have been using the fflib pattern now for some time, and more of our teams are adopting it for our programs of work. My latest addition is something that an architect might wonder why we need; the ability to turn off triggers via a simple interface on all domains.

In an ever growing complex environment, perhaps multiple projects over time delivering iterative enhancements I was noticing a common piece of code being developed within the Domain layer. It looked something along the lines of this:

public override void onAfterInsert()
{
            // if this is set we are already in a loop and want to exit!
            if(bProhibitAfterInsertTrigger)
            {
                        return;
            }

            // down here we do something, maybe insert an Account!
}

While small and inconspicuous it allowed our code base to become inconsistent as there was no control over the exposure of these controlling flags and worse, we were repeating ourselves in every domain!

The solution was simple, a fluent style API within fflib_SObjectDomain. Any code can now simply set the control flags for any domain class:

fflib_SObjectDomain.getTriggerEvent(YourDomain.class).disableAll(); // dont fire anything
fflib_SObjectDomain.getTriggerEvent(YourDomain.class).disableAllBefore();
fflib_SObjectDomain.getTriggerEvent(YourDomain.class).disableAllAfter();

fflib_SObjectDomain.getTriggerEvent(YourDomain.class).disableBeforeInsert();
fflib_SObjectDomain.getTriggerEvent(YourDomain.class).disableBeforeUpdate();
fflib_SObjectDomain.getTriggerEvent(YourDomain.class).disableBeforeDelete();

fflib_SObjectDomain.getTriggerEvent(YourDomain.class).disableAfterInsert();
fflib_SObjectDomain.getTriggerEvent(YourDomain.class).disableAfterUpdate();
fflib_SObjectDomain.getTriggerEvent(YourDomain.class).disableAfterDelete();
fflib_SObjectDomain.getTriggerEvent(YourDomain.class).disableAfterUndelete();

To enable, just call the inverse e.g. .enableAfterInsert(); etc.

While not every code base will need to use these flags, they allow you to control quickly and easily your trigger execution with a single line of code that all your development team can reuse and follow.

[afawcett]

Spot on! Nice work. 👍

Have you found a place to host it, happy to host it for you if not.

Once its up, i'll tweet and promote for ya.

Thanks again! 👍

[Autobat]

Happy for it to end up on your blog

[afawcett]

Done! 👍