I’ve always had a nagging feeling that I wasn’t following best practices in my exception handling in Apex. In most cases I wasn’t doing any exception handling at all. I decided to write up what I have learned about error handling on the Force.com platform so that others could jump into it full-bore, and make their programs more robust and fault tolerant.

I hope it’s helpful to Apex programmers out there. Let me know what you think!

I’m really excited to work with Lucky! This project will be amazing, and Lucky has a longer-term vision. He wants to answer the question: does cloud computing have a role in health systems in rural Africa? He’s planning some really interesting efforts in Kenya later this year. In time, I think Salesforce.com can be a boon in rural Africa, and I’m really interested to start the work to figure out if that time is now, soon, or farther down the road. I see this trip as a great first step on that path.

When I started working with Salesforce.com five years ago, I felt part of my role was to go down the path of trying to deeply customize the platform for nonprofits, and then to report on that experience, warts and all. I really enjoyed that work, and I hope to do similar work and storytelling around Salesforce.com in parts of the world where people assume the cloud can’t work.

But most of all, I’m really excited to have all my assumptions and expectations blown out of the water! I can’t wait to walk the roads, meet folks, and most of all listen and learn. I will be arriving with no answers, and I don’t expect to leave with any. For me, it’s all about getting to the right questions. There will be so much to take in, to start orienting myself to this new set of challenges.

Only just a week ago a friend pointed me to this piece by David Brancaccio on Partners In Health’s work in Rwanda. I was floored by the outcomes they are getting, and the thoughtful design of the community health program. I recommend watching it–it’s amazing.

So many times people look to technology as a savior. That never works in my estimation–human systems are how problems are solved. Technology can augment and transform those solutions, but it isn’t the answer. I’m incredibly excited by what’s already working in Rwanda, and am fired up to start thinking about how technology can help extend that impact.

I watched this video and emailed the link to a friend of mine with the message, “this is the work I want to do with my life–helping people build community-based systems that really work.” Four days later I got an email from Lucky inviting me to Rwanda, to the very region where that video was filmed. Serendipity is a fabulous thing!

Ahh! I’m going to Rwanda! I still can’t really believe it. It all feels so fast and so amazingly exciting. Of course I’ll be writing about the experience, as well as taking tons of pictures and videos. So much to do to prepare!

Groundwire is looking for a top-notch CRM Consultant. Opportunities to join this amazing team are rare. If you are at all interested in using your Salesforce.com skills to make a difference in this world, you should follow up with Groundwire and make sure you don’t miss this chance.

The image on the right is from a Dashboard showing all Contacts in an instance with the Nonprofit Starter Pack installed. All Contacts have been categorized by something called “Donor Status.” We’re looking at their giving and putting them in one of four categories–never a donor, a donor previous to last year, a donor last year, or a donor this year. Here’s how I created it.

First, we need to have 2 rollup summary fields on Account that calculate the Opportunity values over this year and last year. You could also add a third rollup to get the value from two years back:

• Total Giving Year To Date – (Won EQUALS true) AND (Close Date GREATER THAN 12/31/2008) AND (Close Date LESS THAN 1/1/2010)
• Total Giving Last Year – (Won EQUALS true) AND (Close Date GREATER THAN 12/31/2007) AND (Close Date LESS THAN 1/1/2009)
• Total Giving 2 Years Previous – (Won EQUALS true) AND (Close Date GREATER THAN 12/31/2006) AND (Close Date LESS THAN 1/1/2008)

These dates need to be hard-coded for the rollup summaries to work. On Jan 1, you’ll need to add a year to all the dates. Don’t worry, all the rollups will then recalculate for you.

Now you want to show these Account fields on the Contact. Create three formulas that just show the Account field value:

• YTD Giving Total – Account.Total_Giving_Year_To_Date__c
• Last Year Giving Total – Account.Total_Giving_Last_Year__c
• 2 Years Previous Giving Total – Account.Total_Giving_2_Years_Previous__c

Once you have these summary values, you can use them in another Formula, our Donor Status formula:

IF( npe01__Lifetime_Giving_History_Amount__c >0, IF( YTD_Giving_Total__c =0, IF( Previous_Year_Giving_Total__c =0, "2. SYBUNT" , "3. LYBUNT") , "4. Current Donor") , "1. Not Donor")

Note that the npe01__Lifetime_Giving_History_Amount__c field is included in the Nonprofit Starter Pack. The others are fields you just created, so make sure the names match.

Now that you’ve got the formula field built, create a Contact and Organizations report that takes all Contacts and groups by Donor Status. Variations on this report can easily be used to send a letter to everyone who gave in the past but not this year. Once you save this report, you can build a funnel dashboard based on it and you’re done! You’ve now segmented your donors based on when they last gave.

1. Configuring the Starter Pack
2. Importing Contacts via the wizard
3. Upgrading a package

Feel free to fast forward through the first 4 minutes, where we’re getting 110 people logged into their orgs…

But I left Dreamforce feeling transformed–personally and professionally. I didn’t expect it. And I’m not exactly sure what to do with it.

I realized last week the reason I took my current job. People ask me all the time. It was clearly a good fit for my skills. The people are great. And it’s a lot of fun. But I realized the real reason last week.

I took this job so that I can help create better lives for millions of people.

Not tens, not hundreds, but millions. Even hundreds of millions. That’s why I’m on this earth. That’s what I think I can contribute to our shared existence. And I think I can do that in my job.

What brought about this clarity? I met some amazing people. I met one woman who has an amazingly clarity of her purpose in life, and that purpose is to help Africa transform itself. To break the colonial, top-down models and return to self-organized, systemic change, completely in partnership with Africans. No more $1M schools dropped from the sky. Holistic, collaborative, community-based change. Generational change. She burns with this goal, and nothing will stand in her way.

Her passion lit a fire in me. And caused me to ask questions of myself. How does my bug fixing contribute to the reemergence of Africa? Am I making the kind of difference I need to make? What can I do differently?

I met a man who has a full-time job and volunteers with a group working in the Sudan. They are building a school from compressed soil, hand dug, hand compressed, and it will be hand built. I had talked to him about his Salesforce needs before I realized he was a volunteer. I thought he was an employee. But it turns out his organization only has one employee. He quietly does this work in his spare time, because he can’t possibly not do it. That wouldn’t make sense to him. And his work is infectious. He asked me, “do you want to go to the Sudan?” Hell yes I want to go to the Sudan.

I met a woman who is taking a holistic approach to education in Tanzania. Children found abandoned in garbage heaps find a home with her organization. They learn and grow because of her work. Their lives are forever changed. She does this work which has nothing to do with her professional history. She was called to it. And is phenomenal.

These people showed me their fire, their passion, the absolute unacceptability of doing nothing. The necessity of action today. The absolute need for impatience and patience all at once. It bowled me over. I’m reeling from it still.

It has caused me to look at my work differently. I will continue to do the best work I possibly can with the responsibilities I have. And I feel compelled to start initiatives of my own. The first thoughts I’ve had is to make Salesforce.com the absolute standard for use in Africa. Here’s what I think needs to be done to show that Salesforce.com can excel for nonprofits in Africa:

Nonprofit Starter Pack

I need to make this code base the best it can be. I want no software bugs standing in the way of this work. It’s the easiest place for me to make an impact on Monday, and I will.

Language Support

Salesforce is translatable into many languages. At this writing, that list includes 20 languages. English, French and Spanish are official languages in many African countries, and those languages are supported currently. I want Salesforce.com to be available in the next tier of African languages: Arabic, Swahili, Portuguese (Brazilian Portuguese is currently available, and maybe that’s close enough?), and perhaps Afrikaans. There are over 2000 languages spoken in Africa, so we may never get to support Berber, Hausa, Xhosa, and the countless others.

Are these the right languages? I’m new to this, but Arabic, Swahili, and Portuguese seem like the place to start. Arabic is a right to left language, so Salesforce.com first must be able to be switched to that mode, but once that’s possible, I want Arabic the next day.

• Vote for Arabic support on the Idea Exchange.
• Vote for Swahili support on the Idea Exchange.

And as soon as Salesforce.com supports a language, we’ll start the work to translate the Nonprofit Starter Pack to that language.

Offline Support

As you know, much of Africa lacks reliable Internet access. Much of Africa lacks clean water, electricity, and other services much more basic than that. So to support Africans working to transform their countries, we need rock-solid offline tools. Salesforce.com has had offline support in Internet Explorer for years, and many African nonprofits are currently using that to successfully support their work.

Salesforce.com recently released Adobe Flashbuilder for Salesforce a toolkit that includes easy to use offline support. I think we need to build some killer offline apps with this toolkit to show the way in this space. Classroom attendance, health clinic service tracking, micro-finance payment collection. We need to build these and share the source code.

Deep Case Studies

I want to work with a few nonprofits in Africa to go deep in their usage of Salesforce.com. I want to hear the stories of how this helps them achieve their goals, and I want to share those stories with the world. Knowing what’s possible is an important step in the path to impact and excellence. We need to prove it, show it, tell it.

I normally don’t share my goals publicly. I like to under promise and over deliver. That’s worked for me for years. But I can’t seem to contain this new fire I feel. So I’m laying out what I want to see happen and I’ll do what I can to bring it about.

If you feel a stirring when you read this, join me. What will we do? I don’t know. How will we do it? We’ll figure it out. But I need to act today. If you feel that need, drop me a line, and we’ll help Africa together.

First, here is the VisualForce form:

<apex:form id="emailform"  >

<input type="hidden" id="redirect" name="redirect" value="contactus">
Your Email: <apex:inputText value="{!youremail}" id="youremail" maxlength="80" size="40" /><br/>

Subject: <apex:inputText value="{!subject}" id="Subject" maxlength="80" size="40" /><br/>

Message: <apex:inputTextarea value="{!body}" id="Body" rows="6" cols="40"/><br/>
<apex:commandButton value="Send" id="sendButton" onclick="validate3()"/>

	<apex:actionFunction id="emailSendFunction" name="sendEmail" action="{!send}">
		<apex:param name="youremailparam" assignTo="{!youremail}" value=""/>
		<apex:param name="subjectparam" assignTo="{!subject}" value=""/>
		<apex:param name="topicparam" assignTo="{!topic}" value=""/>
		<apex:param name="bodyparam" assignTo="{!body}" value=""/>
	</apex:actionFunction>
</apex:form>

Note that the form doesn’t have an action: we’re invoking code via the onclick action of the command button. When the button is clicked, we’re calling Validate() a Javascript function on the page that looks like this:

function validate() {
     var errorMessage = "Please fix the following errors: \n\n";
     var errorFound = 0; 

     if (!isValidEmail(document.getElementById("about_contact:emailform:youremail").value)) { errorMessage += "Enter a Valid Email Address\n"; errorFound = 1; }
     if (document.getElementById("about_contact:emailform:Subject").value.length == 0) {errorMessage += "Enter a Subject\n"; errorFound = 1; }
     if (document.getElementById("about_contact:emailform:Body").value.length == 0) {errorMessage += "Enter your Message\n"; errorFound = 1; }    

     if (errorFound == 1) {
	alert(errorMessage);
     } else {
	sendEmail();
     }
}

It’s a simple validation scheme. Check a bunch of fields and if they don’t look right, add a message and pop it up to the user. If everything is successful, we call sendEmail().

SendEmail() is the tricky part. It’s actually an Apex controller method exposed as a Javascript function so that it can be called by Javascript. This is done via the ActionFunction tag in Visualforce. You can see it in the VisualForce form above, but I’ll reproduce it here:

	<apex:actionFunction id="emailSendFunction" name="sendEmail" action="{!send}">
		<apex:param name="youremailparam" assignTo="{!youremail}" value=""/>
		<apex:param name="subjectparam" assignTo="{!subject}" value=""/>
		<apex:param name="topicparam" assignTo="{!topic}" value=""/>
		<apex:param name="bodyparam" assignTo="{!body}" value=""/>
	</apex:actionFunction>

The controller’s send method is exposed and 4 parameters are asked for. Each of these parameters are mapped to public variables in the controller, where they are then used by the send method.

public class sffSendEmail {

	public String youremail { get; set; }
	public String subject { get; set; }
	public String topic { get; set; }
	public String body { get; set; }
	public String redirect { get; set; }	// Value tells us where to redirect

	// Constructor
	public sffSendEmail() {
	}

	public PageReference send() {
	 // Define the email
	 Messaging.SingleEmailMessage email = new Messaging.SingleEmailMessage();

	 String[] toAddresses = new String[] { 'destination@email.com' };

	 // Sets the paramaters of the email
	 email.setSubject( subject );
	 email.setToAddresses( toAddresses );
	 email.setPlainTextBody( 'From: ' + youremail + '\n\n\r' + 'Subject: ' + subject + '\n\n\r' + 'Message: ' + body + '\n\n\r' );

	 // Sends the email
	 Messaging.SendEmailResult [] r = Messaging.sendEmail(new Messaging.SingleEmailMessage[] {email});

	 PageReference secondPage = Page.confirmation_page;

	 secondPage.setRedirect(true);
	 return secondPage;

	}
}

If you don’t use the param tags and explicitly map the form fields to the public variables, I found that the send method is invoked before the setters have run on your form, leaving you with null variables. Using the params gets the values into those variables for use.

Update: From the comments, Andrew Waite has a better way of constructing the validate() javaScript:

FYI, it’s a best practice to avoid the dependency on the generated DOM ID, i.e.: document.getElementById(”about_contact:emailform:youremail”. You’ve qualified every element in your path which is good but your code is still susceptible to being broken by a new layer in the hierarchy.
…
The better approach is to define your validation function to accept the DOM IDs as args and use $Component. For example, assume the validate function took one arg for the “youremail” field: function validate(emailid) {….}, and then your onclick would be something like: onclick=”validate({!$component.youremail});”.

Right now we’re at 115% of the number of registrants from last year. Following Metcalfe, and if Dreamforce was tomorrow, that means it would be 128% move valuable this year than it was last year. You can’t argue with math.

But Dreamforce isn’t tomorrow–it starts November 17. If you come, you nonprofit user who hasn’t registered yet, you who has great ideas and insight to share with others, you who has so much to learn, the power of our network increases amazingly quickly.

If we can get to double last year’s attendance, we will acheive 4 times the value of last year’s Dreamforce! It’s true–Metcalfe is right!

This year will be my 4th Dreamforce conference. Every year has been much better than the previous. Every nonprofit organization that has taken the time and effort to use Salesforce.com to help manage their operations should find a way to send at least one staff member to the conference. The information, relationships, and experience will pay off many times the costs of traveling and registration.

If you’re at a Nonprofit using Salesforce.com, or thinking about using it, we currently have a $199 registration rate for you. To get the promotion code, email crmdonation@salesforce.com.

Come be a part of network power. See Metcalfe’s Law up close and personal! Join us in November!

So good news for you! ONE/Northwest is hiring a CRM consultant. You could deliver cutting-edge Salesforce solutions to groups that will change the world with your work. Check out the job description and see if you’re up for some of what I think is the most fulfilling work around!

Want to take a deeper dive into the technical capabilities of Salesforce? Would you like to meet other Force.com developers in the Seattle area? Interested in learning about new/different tools that will help you create and develop better solutions? A new Salesforce user group will be starting up on Thursday Oct 1. Meetings will be held on the first Thursday of every month.

We will try to cover a different range of topics at these monthly meetings such as:

• Summary of new functionality in the upcoming release
• Project spotlight where someone will demo their project and the technical details
• Best Practices
• 3rd Party development and integration tools
• Apex and VisualForce
• Open session to discuss specific questions you may have regarding your current projects

Time: 8-9am
Date: Oct 1, 2009
Location:

West Monroe Partners
1215 4th Ave Suite 1010
Seattle, WA 98161

Please contact Val Grasparil (vgrasparil@westmonroepartners.com) or Andrew Brown (abrown@westmonroepartners.com) if you have any questions.

Since it is in the morning, coffee and snacks will be provided. Please RSVP if you are planning on attending so we can make sure to have enough food for everyone.

As I’ve said many times on this blog, I’m not a computer scientist, so I’m backing into architecture and often the concepts from CS-101 are new to me. I know I’m not the only one, so I’d like to make explicit some of the assumptions that top-notch developers are making every day. I surely am not an expert, and love to have developers set me straight–life is about continuous learning.

I’m going to lay things out as I understand them–if you think I’m making poor assumptions, please comment and set me straight. Also know that one of the reasons I love coding is that it is a creative act. It’s an amazing combination of a highly analytical process and one of inspiration and experimentation. I bet most programmers love that aspect of the job, and so I don’t believe there is a right way to do things, and I hope this may help to unleash creativity, rather than be seen as laying out any kind of Apex dogma that must be followed for fear of wearing the scarlet ‘no software’ mark on your breast.

#1: How hard should you work to have your triggers be absolutely minimal?

I’ve written a bunch of Apex code and also gotten to maintain Apex code written by others. I think writing software for maintainability should be one of the top goals of all coders. I think the most maintainable way to write Apex triggers is to have as little logic in them as possible. If you are trying to figure out how some code works, or doesn’t work, it’s a lot easier to know that the trigger can safely be ignored because it’s only job is to call the class methods that get things done.

But how hard should we try to do that? Should we make sure our trigger has no logic in it at all? If so, it could look something like this:

trigger MyTrigger on MyObject__c (before insert, before update, after insert, after update) {
    MyObjectClass triggerSet = new MyObjectClass(Trigger.new, Trigger.old, Trigger.isBefore, Trigger.Context);
    triggerSet.process();
}

This signature would only have to change if we decide to have this trigger fire in different contexts, like UNDELETE. Of course, it’s not possible now, because there is no Trigger.Context to pass the enum value of the DML context. But, if Jon gets his way and this enum value is created, we have minimized the trigger to 2 lines of code.

But I think there is an efficiency hit. We’re going to instantiate the MyObjectClass no matter what the trigger set includes. If we only want to process records when a certain value changes, wouldn’t it be more efficient to move some logic to the trigger, and only instantiate the object if some of the records in the trigger set need to be processed?

Or is it a negligible difference we shouldn’t worry about?

#2: When should we use static methods vs. object-oriented design?

The trigger above is object-oriented design where an object is instantiated and variables and methods exist for that instance of the object. But the trigger could be written this way too:

trigger MyTrigger on MyObject__c (before insert, before update, after insert, after update) {
    boolean success = MyObjectClass.invoke(Trigger.new, Trigger.old, Trigger.isBefore, Trigger.Context);
}

So which is better? That’s something I’ve never been clear on–George made some great comments on my previous post along these lines.

The static method approach seems to make sense when your methods are straight-forward and you aren’t trying to maintain context across a number of actions. I like static methods for “utility” type functions:

utilities.getRecordTypeName(Id recordTypeId);

utilities.submitMyObjectForApproval(List my Objects);

I personally like the object-oriented approach when invoking a trigger. I think it makes sense to instantiate the object that is going to handle the trigger set, and then kick that off with various methods based on the context and timing of the invocation. It seems to me that writing the code to collect all the data from the trigger is best written once, in the constructor. Here’s some pseudocode for a such a class:

public class MyObjectClass {
     public MyObjectClass()
     {
     }

     public boolean triggerIsBefore;

     public enum context {Insert, Update, Insert, Upsert}

     public context contextPassedFromTrigger;

     public List<MyObject__c]]> triggerOldSet = new List<MyObject__c]]>();

     public List<MyObject__c]]> triggerNewSet = new List<MyObject__c]]>();    

     public MyObjectClass(MyObject__c[] myObjects, MyObject__c[] myOldObjects, boolean isBefore, context triggerContext)
     {
          triggerIsBefore = isBefore;
          contextPassedFromTrigger = triggerContext;

          triggerOldSet = myOldObjects;
          triggerNewSet = myObjects;
     }

     public process()
     }
          // BEFORE INSERT
          if (contextPassedFromTrigger==context.Insert&&isBefore)
          {
               someBeforeInsertMethod()
          }

     {

}

The main difference between static and object-oriented functionality is that you can have multiple independent instances of an object, but not of a static variable. So, if you wanted to deal with 4 different opportunities at once, and maintain data or variables for each and then do some processing, object-oriented is probably the way to go.

Each trigger invocation is it’s own universe. scope-wise, so you don’t have to worry about static invocations conflicting across trigger invocations.

#3: What should go in a static Utils class?

I like object oriented design, and I always compliment that with static classes for “utility” type methods and variables. I think each module of functionality you write should have it’s own utility class that services the other classes you’ve got in that module. I gave the example of the getRecordTypeName() method. Also, all your references to Custom Labels and other strings can be placed in this Utils class, and then they can be accessed statically from your other methods.

#4: What are the limits of class proliferation?

This is a tough one. Let’s say I’ve got some complex functionality. It wouldn’t be at all out of the realm of possibility to have the following:

MyProcess.trigger – my trigger to handle DMLs
MyProcessClass – my main class for handling the trigger
MyProcessUtils – my utils class supporting all this functionality
MyProcessException – a class to extend the exception class for this functionality
MyProcessTest – tests supporting all this code
Other classes for functions that should be instantiatable on their own
VisualForce controllers for any necessary UI

With complex functionality it can get to be a lot of files. So how is this balanced with maintainability? Aren’t more files and more dependencies harder for a maintainer to track down?

It is true that the more classes you’ve got, the harder it will be for someone to find everything and get their head around it. Naming conventions are key to finding related functionality. Everything I write that is related to this process will be started with ‘MyProcess’. Things can get confusing where processes meet and overlap–there isn’t anything we can do about that other than document things well with process maps and other tools.

I think that while there may be a lot of classes in this architecture, and findability my suffer, changability can be enhanced. By encapsulating key functions in their own classes or in well-written methods in existing classes, changes can be more easily made. One thing I’ve learned about writing code is to ‘encapsulate that which is likely to change.’ In the short-term that may seem like a lot of infrastructure for relatively simple code, but when it needs to change it may be a lot easier.

So my main takeaways from this foray into thinking about Apex architecture are:

1. Move most of your logic out of Apex Triggers and into Apex classes. Don’t stress out if your Triggers have some logic in them, but the less the better in most cases
2. Decide where you fit on the spectrum between everything static and everything object oriented, and then be consistent. Maintainability will suffer if you’re changing up all the time for similar functions
3. Use a static utilities class, and be mindful about what goes in there
4. Don’t stress out about class proliferation as long as your doing it to encapsulate that which may change later, and aren’t forgetting about making things finadable

Here’s a trigger architected the first way:

trigger MyTrigger on MyObject__c (before insert, before update, after insert, after update) {

    if(trigger.isBefore){
        if(trigger.isInsert){
            MyObjectInsertBefore myInsertBefore = new MyObjectInsertBefore(Trigger.new);
        }
        if(trigger.isUpdate){
            MyObjectUpdateBefore myUpdateBefore = new MyObjectUpdateBefore(Trigger.old,Trigger.new);
        }
    }

    if(trigger.isAfter){
        if(trigger.isInsert){
            MyObjectInsertAfter myInsertAfter = new MyObjectInsertAfter(Trigger.new);
        }
        if(Trigger.isUpdate){
        	MyObjectUpdateAfter myUpdateAfter = new MyObjectUpdateAfter(Trigger.old,Trigger.new);
        }
    }
}

As you can see from the trigger, all that we’re doing is invoking the correct class based on the starting criteria–are we an insert or an update, and are we before or after? We’ve got a separate class for each of the four cases.

Here’s what two of those classes might look like:

public class MyObjectInsertBefore {

	//create your variables and data structures

    //constructor
    public MyObjectInsertBefore(){

    }

    //constructor accepting a list of myObjects
    public MyObjectInsertBefore(MyObject__c[] myObjects){
        //call whatever methods you need to get the job done
        someMethod(myObjects);
        .
        .
        .
    }
}

public class MyObjectUpdateBefore {

	//create your variables and data structures

    //constructor
    public MyObjectUpdateBefore(){

    }

    //constructor accepting a list of myObjects
    public MyObjectUpdateBefore(MyObject__c[] myOldObjects,MyObject__c[] myNewObjects){
        //call whatever methods you need to get the job done
        someMethod(myOldObjects,myNewObjects);
        .
        .
        .
    }
}

Key to making this efficient is to have shared methods in a MyObjectUtil class, so that similar operations can be reused across your classes.

Here’s a trigger invoked the second way:

trigger MyTrigger on MyObject__c (before insert, before update, after insert, after update) {

	public enum triggerAction {beforeInsert, beforeUpdate, afterInsert, afterUpdate}

    if(Trigger.isInsert && Trigger.isBefore){
        MyObjectClass process = new MyObjectClass(Trigger.new, Trigger.old, triggerAction.beforeInsert);
    }
    if( Trigger.isAfter && Trigger.isInsert ){
        MyObjectClass process = new MyObjectClass(Trigger.new, Trigger.old, triggerAction.afterInsert);
    }
    if(Trigger.isUpdate && Trigger.isBefore){
        MyObjectClass process = new MyObjectClass(Trigger.new, Trigger.old, triggerAction.beforeUpdate);
    }
    if( Trigger.isAfter && Trigger.isUpdate ){
        MyObjectClass process = new MyObjectClass(Trigger.new, Trigger.old, triggerAction.afterUpdate);
    }
}

This trigger sends the old and new sets over to a class and passes the way that this was invoked via an enum value (look up enum in the Apex docs if you haven’t used them–I had to). There is only one class, and then the class sorts out what should happen based on the data:

public class MyObjectClass {

	public MyObjectClass()
	{
	}

	public enum triggeredAction {beforeInsert, beforeUpdate, afterInsert, afterUpdate}

	public MyObjectClass(MyObject__c[] myObjects, MyObject__c[] myOldObjects, triggeredAction ta)
	{	

		// BEFORE INSERT
		if (ta==triggeredAction.beforeInsert)
		{
			someBeforeInsertMethod()
		}

		// BEFORE UPDATE
		if (ta==triggeredAction.beforeUpdate)
		{
			someBeforeUpdateMethod();
		}

		// AFTER INSERT
		if (ta==triggeredAction.afterInsert)
		{
			someAfterInsertMethod()
		}

		// AFTER UPDATE
		if (ta==triggeredAction.afterUpdate)
		{
			someAfterUpdateMethod();
		}

	}
}

You can see that you’re basically accomplishing the same thing–getting the class to invoke the right methods based on the invocation, but that we’re doing it in two different ways. In the first example, we’ve got a proliferation of classes, and each class is very simple. In the second example, we’ve got one class that is more complex as it has to handle many types of invocation.

I ran across the second example in the spring and really liked it. Then I ran across the first example last month and now it’s my favorite. I’m going to try to write new triggers that way and see how they go.

Thanks to Matt and Mike for architecting your code in these really interesting ways! I hope you, like me, love seeing how other people do things–it can really improve the way you code so very quickly.

There also are opportunities for very targeted uses of Sites. With these micro-sites, the investment-to-value ratio can be really high. Here’s an example of one such use case.

The Use Case

A nonprofit wants to have a page on it’s website acknowledging all sponsors who supported events in 2007. They want a simple list of organizations, leaving out any who have asked not to be thanked publicly.

The Data

Sponsorships are tracked as Opportunities connected to the relevant Account. Here’s the Opportunity related list from the relevant Account:

I have created a rollup summary field on the Account to sum up all Opportunities from 2007:

And I’ve created a checkbox to flag Accounts that want to stay anonymous. You can see both fields on the account detail page:

The Display

I want to show a simple list of donors that gave in 2007 and aren’t anonymous. To do this, I need to create a VisualForce page with a simple Apex controller so I can grab the right data, and then display it correctly

Here’s the Apex controller where I’m grabbing the data that I want. You can see from my SOQL statement that I’m only getting Accounts where the rollup field is greater than zero and the anonymous field isn’t checked. I’ve named it donorListing:

public with sharing class donorListing {
	List<Account> accounts;
	public List<Account> getAccounts(){
		accounts = [select name from account WHERE X2007_Giving_Total__c > 0 AND Anonymous_Sponsor__C = false ORDER BY Name];
		return accounts;
	}
}

Here’s the VF Page where I display the data. I point to the Apex I created via the controller attribute of the page. I also turn off the Header, so that I don’t see all the Salesforce navigation elements. Then I just list out the sponsors.

<apex:page controller="donorListing" showHeader="false">
	<apex:dataList value="{!accounts}" var="account" id="theList">
		<apex:outputText value="{!account.name}"/>
	</apex:dataList>
</apex:page>

And here is what the VF page looks like in my browser when I’m logged in to Salesforce.com:

OK, looks great. But I want it visible to people not logged into Salesforce. To do that, I need to create a Salesforce Site.

The Site

You can create a Salesforce site at Setup | Develop | Sites. Create a site, and give it a name. It will show you the URL for this site. That’s the URL people can hit from anywhere on the web to see your VisualForce pages.

You associate VisualForce pages with a Site on the Site detail page. You’ll see here my donorlist page is a part of this site:

Next, I want to make this page visible to the public–I don’t need people to login to see it. That’s done by modifying the public access settings:

Make sure your pages and classes(classes used by VisualForce pages are added automatically) are associated with the site:

OK, now we’re ready to hit the page at it’s external location. For this example, the URL is:

http://smsdev-developer-edition.na6.force.com/sms/donorlisting

The end product

Now that we can see the page publicly, we can embed it anywhere on the web using something called IFRAME. It’s a part of the HTML that runs the web, and has been around for a long time. Here’s the code for embedding this page in my website:

<iframe src="http://smsdev-developer-edition.na6.force.com/sms/donorlisting" width="100%" height="150" frameborder=0>

The nonprofit can now paste that IFRAME code into it’s website content management system. I’ve done just that in this post–you can see the sites page embedded right here:

When you hit this page, you’ll see the live data. If I get new sponsors or I flag sponsors as anonymous, they’ll appear or disappear accordingly. Just manage your data through your normal process and the public acknowledgement just happens.

Heck, you could even put workflow on the Account that automatically sends an email to the Account when they make this list. That email could contain a link to the acknowledgement page. That’s a pretty nice thank you experience for the sponsor, I think.

The challenge

This is a very simple example meant to get you thinking about what’s possible. What do you want to do with Sites? Come up with your own use cases and implement them in a developer org. As you can see, there isn’t much code involved to get it working. Show your boss what’s possible with an example. Tell them how long it took you to get data shared on your organization’s website. Modify the data in Salesforce.com and then hit refresh in the browser. Astound and amaze! And then build Sites into your business process for quick and easy publishing of your Salesforce.com data.

The post tells the full story and provides links to all the relevant resources: project site, issue tracker, code base, and documentation.

Come join us in this effort!