Salesforce Musings

Phone Number with Dial Icon

2014-07-01T23:20:00.000-04:00

Recently while working for a client, I came across a use case where a dial icon was required to be displayed in the Phone Number field. Here are the steps we followed -

Add the dial icon to the Static Resources.

Formula field:

Output:

4 Best Practices for Salesforce.com Code Reviews

2014-06-01T23:17:00.000-04:00

4 Best Practices to Write Great Code

As a technical lead, I often review code written by other developers. Sometimes these code reviews are planned: a client invites us in to review their code, either for training purposes or to address a specific problem. Other times, code reviews are a response to an unexpected emergency: for example, we try to deploy new functionality only to discover that existing unit tests aren’t passing in Production, or, we get a panicked call from a client saying that they’re suddenly seeing Governor Limit errors in code that a long-gone system administrator wrote, and we’re asked to fix the problem that is blocking users from saving their data.

Beginning a review of someone else’s code is always a little stressful. It’s like being called in to clean someone else’s house, where you have to get it clean in 2 hours, but you have no idea how many rooms need to be cleaned or how messy those rooms might be when you start the job. I imagine that house cleaners have pet peeves when they begin a cleaning job (probably things like ferocious pets or unwashed dishes in the kitchen sink.) I certainly have pet peeves when I conduct a code review; things that I find that raise my blood pressure because I know they’re not serving our clients well. Here are a few of my own best practices for code reviews.

1. No Comments

Sometimes I’ll see a trigger with a hundred lines of code, with absolutely no comments except for one line, buried deep within the code that says:

// Increment x

I’ve never understood why some developers don’t take time to comment their code! Every Trigger, Class, and method should begin with a comment block that explains what the code does. Every section of code within a Trigger or Class should contain an explanation as well. (For that matter, complex formulas in Custom Fields, Validation Rules, and Approval Processes should also have comments, but that’s a story for another time.)

It doesn’t take long at all to write a comment. Even a mediocrely written comment can save a ton of time months later, when someone else is trying to make sense of your code. Please, as you’re writing your code, write comments!

2. Non-Bulkified Triggers

Every couple of months, we run across non-Bulkified (or poorly Bulkified) Triggers. These Triggers are usually written by people who are experienced in Java or some other language, but who aren’t used to developing in Apex, and who don’t understand the factors that Salesforce’s Governor Limits require developers to consider. All triggers must be bulkified! This may sound harsh, but if you don’t know what that means, think long and hard about whether you should be developing code that will impact your company’s Production Users! At a minimum, read the Apex Language Reference, especially the section on “Running Apex Within Governor Execution Limits.” And consider bringing in an experienced consultant to review your code and suggest improvements. A little experienced help as you’re learning can help save you a lot of time (and your company a lot of money) in the long term!

3. Hard-Coded Ids

Very often, I’ll run across code with hard-coded Ids like this:

Contact c = new Contact();

c.RecordTypeId = '012700000001du7';

Hard-coded Ids – augh! They’re not self-documenting – looking at the above code, can you tell why it’s assigning that particular Record Type Id to the new Contact, or what Record Type is being assigned? But even worse, if the Record Type was just created in the Sandbox, when the code is deployed and the new Record Type is created in Production, it’ll have a different Id, and the code above will fail.

A much better version of this code would be:

RecordType rtInternalContact = [select id from RecordType

where SObjectType='Contact'

and Name='Internal Contact'];

Contact c = new Contact();

c.RecordTypeId = rtInternalContact.id;

Even though this code doesn’t have any comments, it’s much easier to see what Record Type is being used. And if the “Internal Contact” Record Type has a different Id in Production, this code will use that new Id without any changes. (Don’t forget to bulkify this code – you don’t want to make this query inside a FOR loop!)

(You can also get a Record Type Id using the DescribeSObjectResult object’s getRecordTypeInfos*() methods. See the Apex Language Reference for details.)

4. Unit Tests That Don’t Test

Sometimes, when we look at a Unit Test, we can tell exactly how and when it was written: in a panic, when the original developer tried to deploy some code and realized that they hadn’t written any Unit Tests for it. When that happens, the developer sometimes slaps together Unit Tests that might achieve the code coverage required for deployment, but that don’t actually test anything. How frustrating! The whole purpose of unit tests is to help ensure quality: slapping together unit tests that don’t verify anything only serves to help you deploy potentially poor-quality code to Production!

Unit Tests should test both positive and negative cases. Unit Tests for Triggers should test both individual and bulk DML operations. When you find a problem in your code, you should consider developing a regression Unit Test to prevent a recurrence of the same problem. Developers (and their management) often perceive Unit Tests as a necessary evil. I encourage you to re-evaluate that opinion. A well-written Unit Test can help you find and solve problems long before they’re experienced in Production. Unit tests are your friend!

All of our development estimates include time to write Unit Tests. We don’t consider a coding assignment to be done until adequate Unit Tests have been written for it. We don’t wait until deployment time; we write tests as we go. I strongly encourage you to adopt the same practice.

In Conclusion

How can you avoid writing code that has the kinds of problems described above? First, be aware that the code you’re writing will be running in a production org and that the quality and maintainability of your code could be responsible for generating or blocking millions of dollars in productivity and revenue for your company – so it’s worth the time to write that code properly! Secondly, encourage your company’s IT development organization to develop a Coding Standards document, and then conduct your own code reviews to ensure that you’re following those guidelines. What should go into a Coding Standard document? More on that in a future post.

Diving into Visualforce Controllers

2014-05-01T16:28:00.000-04:00

Very often you would need to either display data from Force.com database or insert data in database variables. Well Force.com platform uses 'Controllers' to do the same task. A 'Controller' is just an APEX code that reads and writes data in the model that is the Force.com database. The variables in the database interact with the presentation layer using "getter" and "setter " methods of the Controller. Using the 'getter' method its possible to get the value of the variable and display it on the Visualforce pages. Similarly a setter method allows the user to change the value of the variable using the Visualforce components like text box.

Now there is something about this Force.com platform which is so majical. It provides default controller implementations called Standard Controllers. These standard controllers provide for the behaviour of native interface like 'editing' or 'creating' records. Now you can also customize these controllers using controller extensions (classes written in Apex). also you can implement controllers which are totally user defined called Custom Controllers.

Lets take a look at a simple example:
TestPage Code:

<apex:page controller="MyController">
   <apex:form>
         Name: <apex:inputText value="{!name}"/>
<apex: outputText value="{!mssg}"/>
<apex:commandLink action="{!Display}" value="Show Message" />
   </apex:form>
</apex:page>

MyController Code:

public class MyController{

      public String name {get ; set;}
      public String mssg {get ; set;}
      public PageReference Display() {
           mssg='Good Morning' + name;
   return null;
      }
}

Benefits of Visualforce

2014-04-01T14:54:00.000-04:00

Visualforce markup language provides a host of benefits. Some of them are listed below:

Easier development: Visualforce allows the developers to write the code for the VF page and immediately see the results after saving in the upper panel. This ease of use saves considerable time for the developers. Also creating a new VF page is extremely easy. You can just enter a URL with a the name of new VF page and the platform will prompt you to create it without even writing a single line of code..!!
Easy Integration with Web-based user Interface technologies: Won't it be cool if we can build VF pages with host of user interface techniques like Flash, Javascript....!! Yes sir you can do it with Force.com platform. Since the VF pages are ultimately rendered as HTML pages in the browser you can combine HTML, Javascript with native dynamic binding fields and do some really cool stuff.
Conformity with MVC style development: MVC refers to Model-View-Controller paradigm. The 'model' here refers to the 'back-end' that is the database design part of the application. 'View' refers to the presentation layer (front end) that is our VF pages itself. 'Controller' refers to the business logic of the application. Such separation ensures easier division of work where Designers can concentrate on designing the VF pages while the developers can quietly play with the business logic.
Compact Code: On an average the amount of code needed is 90% less with VF tags
Hosted platform: This is by far the best advantage. As the VF pages are hosted and compiled by the platform itself. This translates into improved performance
Automatic Upgradation: Your VF pages are automatically upgraded when Force.com platform itself is upgraded. So no hassles there.

In the next post we will discuss advantages of VF pages over S-controls. Till then sit tight and enjoy your Salesforce journey with my blogs.

Introduction to Visualforce --1

2014-03-01T14:31:00.000-05:00

As a Salesforce developer you will face numerous occassions when the users demand custom pages or something different than what Salesforce's native environment has to offer. How do you cater to such situations. Just say 'No Problemo...' and start working on developing Visualforce pages. You can develop custom user interfaces using two ways. One by using Visualforce Components framework or use the automatically generated Page Layouts that Salesforce environment provides.

Lets start with our Visualforce jouney. Note that this will be a series of blogs based on Visualforce and Apex. (Its not possible to cover all topics in a single blog). This blog will give you a brief introduction on Visualforce. Visualforce is basically a component based framework to build custom pages. This framework uses tags to build components that make up a page. There are about 70 components which are already made available by the salesforce framework. But that doesn't mean that you cannot create your own component. The framework allows developers to create custom components.

Visualforce also follows the MVC(Model View Controller) paradigm. Hence the VF (henceforth Visualforce is referred to as VF) pages provide tight integration with the Salesforce database.

Now lets take a deeper look at how VF pages are built and rendered. Visualforce pages are made up of components (custom or already available). These components basically render HTML tags when called from the browser. Once the VF pages are constructed and saved in the salesforce servers the users can access those pages using url links in the browser. The interesting part starts now. When a call is made to the Salesforce servers for those pages, the VF tags are rendered as HTML tags instead and an HTML page is displayed at the browser. (Your browser has no clue how to interpret VF tags). You might wonder why do we need to build VF pages using VF tags then? Don't the HTML tags serve the purpose. Yes, HTML tags serve the purpose and you can very well substitute HTML tags to VF tags. But the main advantage of using VF tags is it reduces the amount of code that needs to be written by about 90%. No wonder Salesforce Developers go gaga about Visualforce and Apex Development platform. This process is explained in the image above.

Now since you know what Visualforce pages are all about (and I hope you are hungry for more). Lets stop it here and we will continue in the next blog post.

Data Loader to the Rescue

2014-02-01T12:30:00.000-05:00

Recently I was working on a Salesforce.com CRM project. I came across a software called Data Loader. Let see in detail.The Force.com platform offers a development environment which you can use to create your own custom applications. Frequently, you will use the Force.com platform to create applications that operate on data that you already have in some form - in comma-separated variable files, spreadsheets or other relational databases.

The Data Loader is an easy to use graphical tool that helps you to get your data into Force.com objects via insert and upsert operations. The Data Loader can also be used to export data from Force.com objects into any of the destinations mentioned above. You can even use the Data Loader to perform bulk deletions by exporting the ID fields for the data you wish to delete and using that source to specify deletions through the Data Loader.

The Apex Data Loader requires the use of the Force.com API (Enterprise, Unlimited and Developer Editions).

Features of the Data Loader include:

An easy-to-use wizard interface
An alternate command line interface
A batch mode interface with database connectivity
Support for large files with up to millions of rows
Drag-and-drop field mapping
Support for all objects, including custom objects
Detailed success and error log files in CSV format
A built-in CSV file viewer
Supported on Windows 2000, XP, and Vista

For more detailed information about the use of Data Loader, check out: http://wiki.developerforce.com/index.php/Data_Loader_Video