They are, the triggers (Basics).
As you probably know, triggers are one of the two Apex types we have to our disposal when developing with Apex. The most relevant difference between an Apex class and a trigger is the particular occasions in which triggers are used. They are related to DML, (Data Manipulation Language) operations. To keep it simple, when and execution operation fires actions like insert, update, delete, and undelete. These operations can be executed in a kind of “time frame”…nothing fancy, we can set the ‘before’ and ‘after’ attributes to our trigger to implicitly tell our trigger when to fire.
An important factor when writing triggers is the fact that they run on system content, meaning this that there is not user reinforcement on access level or access visibility to any of the components you are going to be in used by your trigger.
[code lang=”php”]
//These are the basic first lines on a trigger.
trigger theContactTrigger on Contact (before insert, before update, after insert, after update, after undelete)
{
//Your code here
}
[/code]
These are all the operation types:
A trigger is Apex code that executes before or after the following types of operations:
You should be checking APEX Salesforce documentation to get all details about triggers. I want to talk more about the impact that triggers have on an organization and the discussion of using or not a trigger handlers as a possible solution.
How to start thinking about what should be a good approach? , Some basic ideas.
1. One trigger per object mechanism.
Triggers should contain as less code as possible in their body.
Trying to avoid this will already be a solid base for your trigger structure.
2. Remember that triggers do not reinforce system restrictions or access levels to records.
This is again a reason why you should move your code out of the trigger body.
3. Try to delegate the triggers DML operations to other classes.
This is really important and the foundations of a good trigger structure, well known as best practice.
So let’s take a look at one simple piece of code:
[code lang=”php”]
//These are the basic first lines on a trigger.
trigger theContactTrigger on Contact (before insert, before update, after insert, after update, after undelete)
{
//This first line will make sure that we invoke our class only in ‘before update’ operations.
if(Trigger.isBefore && Trigger.isUpdate)
SetContactStatus.contactStatusMethod();
}
[/code]
What we have done is to pass all responsibilities to another class. We invoked the method ‘contactStatusMethod()’ from the class ‘ChangeContactStatus’ to run our logic.
This is the simple operation that will update the custom status field to active if no values are there:
[code lang=”php”]
public with sharing class SetContactStatus {
public static void contactStatusMethod()
{
for(Contact c: (List<Contact>) trigger.new)
{
if(c.Status__c == null)
c.Status__c =’Active’;
}
}
}
[/code]
There are a few things that we are doing here that are not really basics. If you take a look to the like:
[code lang=”php”]for(Contact c: (List<Contact>) trigger.new)[/code]
We are doing some casting here. The class that we are using don’t really have a relation to the SObject we are using in our trigger, so we are making sure that what we are passing are Contacts records, and we do this by casting the context of the ‘trigger.new’.
Will be adding more details soon.