Visualforce design pattern: a dynamic approach.

Introduction

Salesforce comes with numerous configuration and customization options for building business applications with varied target audience. However the more we try to customize the more we lose the massive benefits that Salesforce comes with OOB. Here we will focus ourselves to issues with visualforce page only. We will analyze the issues and try to provide one design pattern that solves most of them.

Problem:

●     Visualforce page destroys all the benefits that come with page layout. Once we replace a page with visualforce page we can no longer rearrange the fields and add new fields to the page. We can easily remove any field from a VF page by changing the FLS under profile settings; however it comes with a recurring configuration effort for new profiles.

●     In production we may need new record types and associated new page layouts. This increases the effort. As we need the entire visualforce page to be re-written to handle new record types and perform all the associated work. If the code in production is from an installed managed package life becomes much more difficult as in this case we have to create new visualforce page, new controller extension and all associated codes in production. Also this exposes the code from managed package which in most cases is not an option.

●     Handling multiple record types in a single visualforce page makes the page code heavy; difficult to read and debug which directly impacts the maintainability of the code in all aspects.

Solution:

We will focus on a solution leveraging field sets. Following is the definition of field set from Salesforce documentation:

“A field set is a grouping of fields. For example, you could have a field set that contains fields describing a user’s first name, middle name, last name, and business title. If the page is added to a managed package, administrators can add, remove, or reorder fields in a field set to modify the fields presented on the Visualforce page without modifying any code. Field sets are available for Visualforce pages on API version 21.0 or above. You can have up to 50 field sets referenced on a single page.”

In one field set we can define a set of fields, order them and can mark fields as mandatory. We can create multiple field sets and use them in one visualforce page. It addresses issues discussed above to a great extent, however field sets has some limitations:

●     We do not have any provision to capture order of multiple field sets.

●     One field set can represent one section of a page and can contain the fields of the section. But field set cannot capture any other information like section header, number of columns etc. regarding the section.

●     Field sets cannot be related to any record type by configuration.

We will address these shortcomings using the description information of the field set. JSON is our chosen format to store this information for its lightweight nature. Here is one sample format:

{

“RecordTypeName” : “Complaint”,

“Order”: 1,

“Columns” : 2,

“SectionLabel” : “Action Taken”,

“Description”: “Used In edit Page”

}

Description field can hold up to 1000 characters. The above simple information takes only 116 characters and it contains all the information required to overcome all the shortcoming of field sets mentioned above. Undoubtedly we can accommodate all the required information, including the above, suited for almost all practical scenarios.

Let’s focus to the implementation of the visualforce page that will take into account the entire field sets of the corresponding object and render the fields as applicable in proper order and with proper sections. The implementation has three parts:

●     A service class that will resolve all applicable field sets and arrange them in proper order with all the associated information. For the sake of clarity we will use one wrapper class to encapsulate each field set and generate a list of them. Here is the pseudo code for the service class,

●     Secondly we need a controller extension class that will invoke the service class and provide it all the runtime information and receive the output from the service class for consumption by the actual visualforce page that will render the actual display. Pseudo code for the controller extension is as follows,

●     Finally we need a visualforce page that will consume the list of field sets wrapped in the wrapper class mentioned in first point above and render the page accordingly. Code snippet for the visualforce page is given below,

Sample Code:

A full set of code is available in an unmanaged package, click here to install it to your org. Along with the service classes this package also contains a demo code for account edit page. Override your existing edit and create actions for Account object by the supplied visualforce page ‘accountEdit’. The package comes with two field sets ‘Account Information’ and ‘Contact Details’ containing some standard fields. Visualforce page ‘accountEdit’ renders the fields from the two field sets in two sections using the design pattern discussed above. Feel free to modify/remove the two field sets, add new field sets and see the changes in the account edit page.