Wow, every day we learn something new so It seems like I’ll never run out of material for my list of commandments!

Here’s the continuation of my previous list, it’s important to point out that some of these might not be valid for future releases but people should be careful for now when dealing with some of the current limits. So here we go…

Thou shall not:

• Assume that standard objects in destination orgs don’t have any validation rules/trigger logic that will cause your package’s test units to fail, place your catch blocks and take actions accordingly
• Assume your custom settings will be initialized when running test units in a destination org , make sure you validate null values or set the values for custom settings
• Give end-users credentials to test your app and go on vacation leaving the user wondering what the heck is a verification code. Make sure you change the f$!@#%^ email address!
• Leave out apex:pageMessages component from your VF page to display any errors (unless your page is used for other purposes)
• Forget to add a status indicator in your VF pages when doing async stuff
• Forget to test and probably fix the behavior of the “enter” key in custom VF pages
• Expect cascading delete operations to execute trigger evaluations on those records that did not initiated the delete operation
• Forget to use Test.startTest() and Test.stopTest() methods inside test units
• Assume that you can run a report on humongous amount of data, make sure you plan your report filters and create external ids (indexes) accordingly
• Assume you can use a Long Text area field in a formula field or SOQL where clause
• Assume that Force.com can handle all type of attachments , there’s a limit of 5 MB!
• Leave the endpoint for a WSDL to Apex generated class (or any endpoint value) as a hardcoded value, make sure it can be changed through custom settings
• Create a VF page just to show an image, use IMAGE in formula fields!
• Ignore revoked tokens scenarios when using OAUTH
• Use Contacts without Accounts, these are always private regardless of your organization’s sharing model
• Forget that text names for custom objects have a max length of 80 characters
• Forget there’s a data loader built into salesforce
• Ignore the use LogLevel for debug statements
• Create tabs for objects that don’t really need a tab
• Assume auto-numbers will always be sequential, numbers will keep increasing but data creation in test units will break the sequence
• Forget that once a master relationship has been established it CANNOT be changed
• Create public utility classes for test data creation without the @isTest annotation (Winter 12)
• Pretend that no one is using the production org while you’re doing your deployments
• Forget that a profile is tied to a type of license
• Forget you can actually know the total number of records for specific objects just by going to Setup>Data Management>Storage Usage
• Create a ton of single static resource for your VF pages, use a damn zip file
• Assume SF to SF will copy all of your lookup relationships
• Miss new platform releases webinars or not visit http://blog.sforce.com
• Fall for jeff douglas blog phantom results in Google… but you’ll probably will anyway…

I’ve been working a lot with rails and force.com during the last months, rails is awesome however getting all of the plumbing to work is a real pain. I’m working on a template app that might be helpful for anyone that’s trying to build a rails app that interacts with force.com.

This app template uses:

Databasedotcom gem
Bootstrap framework
Application template
Basic chatter components (more info below)

I decided to use cells for creating reusable components and it’s looking very promising. I created a few chatter-related components and got it to a point were the following code:

<table class="profile">

	<tr>
		<td style="vertical-align:top;">
			
			<div style="width:100%;">
				<div style="width:220px;float:left;">
					<%= render_cell :ProfilePhoto, :display , :uid => current_user.id, :size => 'large' %>
				</div>
				<div style="width:300px;float:left;">
					<%= render_cell :UserStatus, :display , :uid => current_user.id %>
				</div>
			</div>

		</td>

		<td>
			<%= render_cell :AboutMe, :display , :uid => current_user.id %>
		</td>

	</tr>

</table>

Renders the following page:

I’m no expert in ruby or rails so I hope that with the help of other developers we can improve the template and expand the components library.

Also, i’m planning to provide some libraries to access the metadata api from ruby but this is still a work in progress.

You can checkout the github project here.

Good stuff is coming for the Summer ’11 release of the Force.com platform! My personal favorites: dynamic components and javascript remoting, these 2 features will save a lot of headaches when working with Visualforce and I’m already thinking of several pages that I could optimize by using them.

Anyway, every new release comes with very interesting features but there’s still a feature that I’d wish Salesforce could improve and it has to do with auto-number names for records. Why? Well, because these records are hard to find. There are cases where you definitely don’t need to setup a special name for records and any identifier will work but I’ve come across several cases in which users need to select a record that has an auto-number name through a lookup dialog and always end up with complaints about the search functionality for these records. This could be solved by telling users to use a naming convention for the record and avoid auto-number names but it’s hard to assure naming conventions will be followed and since the name field is a required field you cannot set it through a trigger or workflow unless you make some workarounds with Visualforce.

These situations usually happen when we have an object in which the record name is hard to define since it may describe several things  and these  usually end up being records of junction objects. For example, let’s look at the following situation with the well-know Recruiting app.

We have a junction object called Job Application and we name it JA-{00000}, everything works fine at first but as our application continues to grow we might end up creating an object such as “Interview” that we must link to a “Job Application”. If you wanted to create an Interview record directly from the “Interview” tab and link it to a Job App through the lookup dialog, well… you’ll need to know the auto-number name for the Job Application or hope it comes up in the recently viewed records, although Salesforce gives us the option to set the columns for the lookup dialogs there’s no easy way to search within the list for this type of records.

I think any of the following options could help a lot in this situation:

1.- Search by other fields within lookup dialogs, not just name fields

The good:

Minimum impact and it would involve a small amount of configuration tasks since we would probably just need to set some of the fields as external ids to create indexes so that we can search on these.

The bad:

There might be some cases where we might need to create workflow rules for concatenation purposes.

We won’t be able to display more info of the record in the auto-number name.

2.- Give the option for removing the required option from the name field

The good:

Gives us the flexibility to set the name through workflows or apex triggers (for more complex situations).

This could be useful for objects in which you might want to create a name depending on the record type, the name field could be hidden from a specific layout and then filled in the background through workflows or triggers.

The bad:

If no name is defined, we might end up with records having the Id of the record as a name and that is a bad thing.

3.- Define an auto-number as a formula field

The good:

Gives us a lot of flexibility for setting up the record name without using any workflow or apex trigger.

The bad:

Probably hard for the platform since it would need to construct an index based on a formula field and I guess that if this is possible it could hurt in performance.

In my opinion, option 1 is probably the best since it seems like the one that has less impact but I wish the platform could offer the flexibility of option 2. I’d  appreciate any feedback on this from everyone out there, there are already  some ideas related to this subject so please vote for them so that we can see this solved in a future release.

Here’s a list of some of the ideas related to auto-number fields:

• Allow Record Name to be formula field while allowing autonumber
• Improve Enhanced Lookup Search Capabilities
• Lookup Search Fields For Custom Objects

I spent a few minutes today thinking about my experiences developing on the Force.com platform. Overall it has been great, nevertheless, there have been some bumps in the road (and there will be more to come).

Here’s a list of some commandments that I’ve come to think of as imperatives for development on Force.com.

NOTE: This is just a list with no particular order of some of what I consider are the most important items.

Thou shall not:

• Say a class or trigger is ready without having any test units
• Place a SOQL query inside a for loop
• Place a DML operation (for a single record) inside a for loop
• Hardcode an id, object prefix or service instance names… anywhere
• Create a full sandbox without being damn sure you’re ready to create it
• Say a field is hidden by just removing it from a page layout
• Assume your test units will magically find data in a new org
• Assume a 75% coverage is good
• Ignore asserts in your test units
• Rely on good percentage coverage of other classes to upload your “I must get this to production right now” code
• Prefer a trigger over a validation rule (if it can be done through a validation rule)
• Create a new trigger for an object each time you want to add something new unless you’re pretty sure of what you’re doing
• Ignore the undelete event in a trigger
• Assume a trigger will process a single record
• Create all of your classes with “without sharing” keyword unless you know what you are doing
• Leave open queries (without a where clause or limit) unless you know very well your data
• Ignore the escapeSingleQuoutes function to “clean” user-supplied input in dynamic SOQL
• Keep list of objects as part of your viewstate … again … unless you know what your are doing
• Create a custom object for saving custom settings
• Look for a RecordType based on the Name instead of the DeveloperName
• Ignore the certification maintenance emails
• Reset a security token without taking in account existing integrations or other people that may be using the token
• Have a mac and not use SoqlXplorer
• Use chrome and not use the “Force.com utility belt” and “Force.com Logins” extensions
• Ask questions like crazy unless you already searched in the discussions boards and found no answer
• Use accents in profiles or page layouts names (for those that use Spanish)
• Change the type of a lookup relationship without taking in account any impact on the standard report types and reports that are currently using those report types
• Suspend a user without thinking about re-assigning ownership of his/her records
• Ignore declarative changes in production, always keep track of these changes
• Avoid the use of Security Code Scanner to resolve thy issues — Cory Cowgill

Amen.

These are some important considerations for those who plan to build apps for the Force.com platform, these considerations are organized by Data, Logic and User layers.

In conclusion, the ideal Force.com profile is one that works with:

• Structured data, search, reports
• User-driven business processes
• Employee,customer or partners users
• Real-time information, mobile or collaboration needs

Here’s a nice tool from Google for building apps for Android:

Learn more here : http://appinventor.googlelabs.com/about/

Google just released new features for Google Docs, including a new addition to the suite called Drawings!

As a user of google spreadsheets I was very aware of performance issues when working with large data files and this new version of the application seems to boost performance and at least scrolling seems to work very well.

These are some great enhancements to the Google Docs suite and hopefully this brings more ideas for integrating Google Docs with Force.com through the Google Data API Toolkit.

Here’s a video with more info:

Hello again!

I just developed an Apex class for performing replace/merge operations on any kind of object, and yes any kind of relations as well! , so it doesn’t matter if you have master-detail relationships that can’t be modified, objects tied in a master-detail relationship will be cloned, deleted and inserted with the new values to simulate a merge operation!

To use the Merge class  just create an ObjectMerge instance, passing as an argument of the constructor your current record:

ObjectMerge oMerge = new ObjectMerge(SourceObject);

And to peform the merge operation just use the replaceRecord method and thats it!, you can specify if you want to delete the source record after the merge operation is done.

oMerge.replaceRecord(MergeToThisObjectID,DeleteSourceObject);

You can limit the number of records that will be processed in the merge operation for Master-Detail relations  to avoid hitting governor limits. The ObjectMerge class will let you know if there are any objects left, and if this is the case just continue performing the merge operation.

Force.com provides a merge DML operation but it’s only available for some of their standard objects, this class can help you get around that. There are still some limitations with this class due to governor limits in the number of describe calls but unless you have a large amount of objects related to the replaced/merged record it should work pretty well.

For now, the Object Merge class only merges/replaces custom objects related to your record, but this can be changed  in the class , however keep in mind that no more than 10 relations can be processed due to describe calls limitations so be careful when removing the custom objects limitation because there can be many Non-Custom objects related to your record.

I’ll leave a link in this post to the files but for now here’s an example of how to use the ObjectMerge class in a VisualForce controller that merges contacts, if you have custom objects tied a contact A and want to merge contact A to Contact B you will see how the ObjectMerge class changes all of the objects from contact A to contact B then deletes contact A. Remember, you can try it with any custom object   Enjoy!

Download the files from here –> ObjectMerge

public class MergeController{
    
    //This is just an Aux Object to get a Lookup Field in the VisualForce Page
    public Contact MergeAux{get;set;}
    //Declare an instance of the Object Merge Class
    private ObjectMerge oMerge;
    //Save the current contact in the controller (optional)
    private final Contact currentContact;
        
    public MergeController(ApexPages.StandardController controller){

        //Initialize all of our objects
        currentContact = (Contact)controller.getRecord();    
        MergeAux =new Contact();
        oMerge = new ObjectMerge(currentContact);        
        
    }
    
    //Merge Action
    public PageReference doMerge(){

        try{
     
            //Run the merge operation!, you can specify a second argument to delete the record after merge or not
            oMerge.replaceRecord(MergeAux.ReportsToId,false);
            
            //Do corresponding actions if merge operation was successful
            if(oMerge.bAppliedReplace){
                PageReference ref = new PageReference('/'+MergeAux.ReportsToId);
                ref.setRedirect(true);
                return ref;
            }else{
                return null;


        }catch(Exception e){
            
            ApexPages.addMessages(e);
            return null;    
        }
        
    }   

}

//And the Visual Force page will look something like this:

<apex:page standardController="Contact" extensions="MergeController">
     
     <apex:form >
         <apex:pageBlock >
             <apex:pageMessages id="messages">
             </apex:pageMessages>
             
             <apex:pageBlockButtons >
                 <apex:commandButton value="Merge" action="{!doMerge}" rerender="messages"/>
             </apex:pageBlockButtons>
             <apex:pageBlockSection columns="1">
                 <apex:outputField value="{!Contact.Name}"/>
                 <apex:inputField value="{!MergeAux.ReportsToId}"/>                
                 
             </apex:pageBlockSection>
         </apex:pageBlock>
     </apex:form>
     
</apex:page>

(NOTE: There’s a bug with the code viewer plug-in, please ignore the second viewer)

Hello everyone!

I came across a blog post at gokubi.com (http://gokubi.com/archives/two-interesting-ways-to-architect-apex-triggers) about some interesting ways of architecting Apex Triggers.

We have developed a lot of logic in Apex Triggers and ended with some really nasty code in some scenarios; this post got me thinking about new ways to architect triggers using a more object-oriented approach. So just to follow the thoughts in this post I’ll show you what I did to organize our triggers and it has been working pretty good so far.

NOTE: Please refer to the code section below

//Step 1

I started by creating an Apex Class to replicate some of the triggers functionality…

//Step 2

The next step will be to start coding our Apex Class that will perform all of the logic in our triggers, so let’s say the we are building a trigger for My_Object__c custom object.

//Step 3

And finally, we just need to create the Apex Triggers that will just initialize our Trigger class and initialize an instance of the corresponding Apex Class that will handle all of the logic.

And that’s it! Just remeber to cast the the collections correctly before accessing the collections from the ExtTrigger class because we can’t work with generic sobject collections.

Some of the benefits that I’ve seen by organizing Apex Triggers in this way are the following:

• 100% Test Coverage in Apex Triggers (although all of the Test Coverage should be done in the handler Apex Class)
• Since we can call functions to perform specific actions in Apex Classes, we end up with more organized code, it’s easier to read in the sense that you can just go to see the calls inside the “onBeforeInsert” section for example..
• Avoid the max number of characters governor limit:
  • Maximum number of characters for a class: 100,000
  • Maximum number of characters for a trigger: 32,000

Thanks to everyone that posted in gokubi’s blog post any feedback on this is appreciated

Salesforce’s Spring ’10 is packed with some really nice enhancements, new interface, code scheduler, no limits in collections, and more!

For more information go to: http://developer.force.com/releases/release/Spring10

Here’s a small demo of how code scheduler works: