Redkite

Ran into a strange “bug” today while developing a VF page.

This VF receives parameters through the URL which the VF Controller class parses out and stores in a class variable. The VF page also has an <apex:outputPanel> section which is rendered if the URL parameter equals a specified Custom Label. The code looks like the following:

Example URL:
https://na#.salesforce.com/apex/MyPage?param1=paramValue

Example Custom Label Definition:
Custom Label Name : MyLabel
Custom Label Value : paramValue1

Example Visualforce Page:

<apex:page controller="MyController">
 <apex:outputPanel rendered="{!ctrlParam1=='$Label.MyLabel'}">
  <apex:outputText value="Hello, World!"/>
 </apex:outputPanel>
</apex:page>

Example Controller Class:

public class MyClass{
 public String ctrlParam1{get; private set;}
 public MyClass(){
  map<string> params = ApexPages.currentPage().getParameters();
  ctrlParam1= params.get('param1');
 }
}

With the configuration details setup as above, the <apex:outputPanel> is not rendered. More specifically, the code rendered="{!ctrlParam1=='$Label.MyLabel'}" evaluates to false.

Playing around a bit with this code, and a lot of head scratching, netted me the following code that does work:

rendered="{!ctrlParam1==$Label.MyLabel}"

(No quotes around the Custom Label). I guess $Label.MyLabel is a variable in and of itself, and not a replacement string as I assumed that it was. Wish Salesforce.com Help and Training had more sample code. Grrr..

Add a Comment »

Just a little lesson learned as to how Scheduled Classes are treated in Salesforce.com.

When a class is scheduled for execution using the “Schedule Apex” button, the class is instantiated immediately and then held in memory until the time it should run. This means that the constructor code of the scheduled class is run when the Admin creates the schedule for the class and not at the time the code is meant to execute.

This is an important distinction and can cause some issues if you’re not careful. Let’s take an example:

global class MyClass implements Schedulable, Database.Stateful{
 MyCustomSetting__c settings;
 public MyClass(){
  settings = MyCustomSetting__c.getInstance();
 }
 global void execute(ScheduableContext ctx){
  String localCopyOfSettingsField = settings.mySettingsField__c;

  ...

 }
}

So in the above code, the MyCustomSettings__c object is loaded at the time the scheduled job is created. So if, for example you have scheduled this class as a weekly job, and you decided to change the value of the mySettingsField__c field after you created this scheduled job, then the Class would not pick up the value for the next scheduled run, as the class has already been instantiated and already taken a reference to it’s copy of the Custom Settings object. You can see how this can be annoying.

If you do find yourself in this situation, you can always delete the scheduled job and re-create it, which would force the code to re-instantiate the class.

The proper long term fix would be to move code that you want to execute at run time into the execute method, since that code has to run at the time of execution.

global class MyClass implements Schedulable, Database.Stateful{
 MyCustomSetting__c settings;

 public MyClass(){
 }

 global void execute(ScheduableContext ctx){
  settings = MyCustomSetting__c.getInstance();
  String localCopy = settings.mySettingsField__c;

  ...

 }
}

Add a Comment »

Salesforce.com’s inclusion of the Custom Settings feature was a much welcomed addition to the Visualforce / Apex feature set.  I’ve been using it fairly regularly in my day to day development for close to a year now and I just wanted to share some thoughts on “Best Practices” in how to use these two types.

I have been using Custom Settings, as I’m sure most of you would, as substitute a configuration file.  Placing “hardcoded” values into this object and changing out values when needed.  Before Custom Settings came out for Apex, we’d use a variety of methods including a “config class”, custom objects, and even custom labels.

Initially, I had used List style custom settings almost exclusively, as it seemed much simpler since it behaved very much like any other Custom Object in Salesforce.com.  Also, it was a  was fairly similar to my Java experiences where we would create separate config files per environment.  So I imagined that I would create a separate config for our production Salesforce.com instance vs. our sandbox instance.  But in practice, what would happen more often than not since most of our development was purely native Salesforce.com apps (i.e. Visual force pages which work on data within Salesforce, and are not connected externally to any servers), was once the code was deployed into production, there was very little need for any other configuration other than the production version.

Also, there were times where I wanted to reference these config values outside of Apex code, for example in a formula field or an email template.  This is where the Hierarchical Custom Settings has an advantage.  Hierarchical can be accessed in other parts of Salesforce.com which may work in conjunction with an Apex package.  Formula fields, Workflow Criteria, and Email Templates are examples of things that can access Hierarchical Custom Settings and not List Custom Settings.

Hierarchical Custom settings also have the added benefit of being able to handle those one-off “corner case” users that always seem to come up in large organizations.  If you have a user who could benefit from a slightly different app configuration, the Hierarchical Custom Settings is built specifically to handle different config settings for different users.

Update: One really good scenario for using List custom settings are when you have a common reusable piece of code, like for example a custom list view, that you use in many places throughout Salesforce. This list view can be supported by a custom list config where the name signifies where in the app the list appears, e.g. ContactDetail, AccountDetail, AccountListView, etc.

Summary

So just to summarize what I feel is the right way to use these different types of Custom settings: Hierarchical Custom Settings

• Use this for your most of your VF/Apex config settings for stand alone apps
• Don’t put in settings which are environment dependent (e.g. if you have separate test server URLs that should be used in Sandbox vs. Production)
• Definitely, if you are storing User Preferences, Hierarchical is the way to go.

List Custom Settings

• Use this if you creating config for a common piece of code that appears in different areas of Salesforce
• Use this when there are environmental differences such as Test server URLs vs. Production server URLs
• Also can be used as a simple table for frequently used data

Of course you can us a combination of Hierarchical and List settings in your application and use each to its strengths.

Add a Comment »

Our LinkedIn Connector for Salesforce is now the most popular free app on the Appexchange!

Get in on the action here.

Congratulations to Greg Mahoney at HarbourVest Partners, winner of our iPad raffle. Thanks to everybody who visited us at Dreamforce and to everybody who installed our LinkedIn Connector for Salesforce (currently the 3rd most popular free app on the Appexchange).

We’ll be at Dreamforce again in ’11 – drop by again in August (!) and see what’s new.