[SF1] Return of nofunc: Apex Templates

Quite some time ago, I started a series of blog posts that were all about creating an org/repo which was technically not functional - but existed as a starting point for functionality. Similar to how the excellent mavensmate offers the ability to not just create an Apex class that is blank, but starting templates depending on the task at hand.

The nofunc repo is up on my github account and I thought I would review the two classes that got created before I start hacking back into the new project over the next couple of weeks.

Purely alphabetically, the first one is AsyncApex which breaks down functionality like Batch and Scheduleable:

global with sharing class AsyncApex implements Database.Batchable<sObject>, Schedulable, Messaging.InboundEmailHandler {
//To use a callout in batch Apex, you must specify Database.AllowsCallouts
//   IE: implements Database.Batchable<sObject>, Database.AllowsCallouts{}
//use Database.Stateful to maintain state between jobs  

//global or global
global AsyncApex() {}

The class breaks down the key interface methods required for both scheuled:

//--- Scheduled Apex
global void execute(SchedulableContext ctx) {
        //currently SchedulableContext has one method: getTriggerID
        //use System.abort() to stop execution

        //Scheduled logic
        //UtilityClass.method();

        }

And batch:

  //--- Batch Apex         
global Database.QueryLocator start(Database.BatchableContext BC){
        //similarly, BatchableContext has getJobID method

        //update SOQL for your query locator
        return Database.getQueryLocator('SELECT ID FROM Opportunity WHERE Status__c = \'Closed\' AND CreatedDate < LAST_90_DAYS');
        }

global void execute(Database.BatchableContext BC, List<sObject> scope) { 
        //perform logic and DML
        //upsert scope
        }

global void finish(Database.BatchableContext BC) { 
        //send notifications, final clean up
        }

As well as one of my favorite Apex tricks, inbound emails:

//-- Inbound Email      
global Messaging.InboundEmailResult handleInboundEmail(Messaging.inboundEmail email, Messaging.InboundEnvelope env){}

And of course, outbound as well. The other class is VisualforceController and it breaks down the basics of a controller class - including supporting both extensions and custom controller and common actions within those, like checking for incoming params:

//Custom Controller Constructor
public VisualforceController() {
/*  //check the existence of the query parameter
    if(ApexPages.currentPage().getParameters().get('id') == null) {
        ApexPages.addMessage(new ApexPages.Message(ApexPages.Severity.FATAL,'No Id Found'));
        return;
    }

And, of course, methods for both bound components and RemoteAction - including a sample custom JSON response:

//You don't need this to return results for RemoteAction, but creates structure
public class JSONResponse {
    public string message;
    public Account data; //Modify to your actual datatype
    public JSONResponse() {}
}

I think the obvious next one is a trigger, which will probably use the "One Trigger Per Object" rule of design I generally advocate. Eventually nofunc could be used to create a kind of boilerplate org to speed up new applications. I have not decided if that means I will combine it with my (now dated) regular-sr repo where I track static resources I use frequently (like jQuery).

But probably.

comments powered by Disqus