In this chapter, we will cover the following recipes:
Preventing duplicates by searching before creating
Editing a record and its parent
Managing a list of records
Converting a lead
Managing a hierarchy of records
Inline-editing a record from a list
Creating a Visualforce report
Loading records asynchronously
When Visualforce pages utilize a controller extension or custom controller, they can retrieve additional records via SOQL queries. This allows pages to manage more than one record, regardless of the record sObject types or whether there is any relationship between the records.
The Salesforce Object Query Language (SOQL) allows information to be retrieved from the Salesforce database based on supplied criteria. It has an SQL-like syntax, but does not support advanced operations such as wildcard field lists.
In this chapter, we will explore a number of scenarios to manage multiple records on a single page, ranging from a single record and its parent to a deep and wide hierarchy.
We will also see how Visualforce can be used to present details of a collection of records in response to user-specified criteria, in order to search for existing matches before creating a new record or to produce a custom report page.
A very common problem in Salesforce implementations is duplicate data. While training users to search for existing records before creating can help, this relies on users remembering to follow the process, which can be especially problematic if some users create records on an infrequent basis.
In this recipe, we will create a Visualforce page that overrides the lead sObject create button and requires a user to search for existing matching records before they are allowed to create a new record. In order to avoid the user having to rekey data in the event that no matches are found, the search criteria is carried through to the create page.
This recipe makes use of a controller extension, so this must be created before the Visualforce page.
A Visualforce page managed by a standard controller can provide the edit capability for a record and its parent. However, when the standard controller Save method is invoked, the object graph is not traversed and only the record being managed by the controller is saved.
In this recipe we will create a Visualforce page to allow a user to edit fields from a contact and its parent account. Saving the record will also apply any changes made to the parent account record.
This recipe makes use of an extension controller, so this will need to be created before the Visualforce page.
First, create the custom controller by navigating to the Apex Classes setup page by clicking on Your Name | Setup | Develop | Apex Classes.
Click on the New button.
Paste the contents of the ContactAndAccountEditExt.cls Apex class from the code download into the Apex Class area.
Click on the Save button.
Next, create the Visualforce page by navigating to the Visualforce...
Salesforce users often require the capability to work with a number of records at once. For example, a sales user may be communicating with a number of contacts, while he/she may also be creating or deleting contacts in response to information received through a number of channels. The Salesforce enhanced list view functionality allows a set of records that share a common record type to be inline-edited, but doesn't provide a way to add or remove records.
In this recipe, we will create a Visualforce page to allow a user to edit the details of a collection of existing contact records, and create or delete records dynamically. Upon saving the list, existing records will be updated, any new records will be inserted, and any records previously deleted from the collection will also be deleted from the database.
The standard Salesforce lead conversion page allows a user to create a new account and contact record or merge with existing records, and optionally create a new opportunity record. Information from the lead is copied to the existing or new records based on the lead field mapping configuration. If a user wishes to specify information after clicking on the Convert button, they must exit the conversion and edit the lead record.
In this recipe, we will create a Visualforce page to allow a user to convert a lead and in addition to creating or merging with existing records, populate additional fields on the opportunity that is created as part of the conversion.
This recipe makes use of a controller extension so this must be present before the Visualforce page can be created.
Salesforce records often form part of a deep and wide hierarchy; for example, an account can contain a number of cases, each of which can have a number of comments associated with them. Creating and maintaining the elements of the hierarchy in isolation is a cumbersome and time-consuming task, as to add a comment a user must click through from the account record to the case record, and then click on the New button on the case comments related list to open the new comment page.
In this recipe we will create a Visualforce page that allows a user to maintain an account, its associated cases, and the comments associated with those cases. The user can update or delete existing records, or create new records at any level of the hierarchy.
In the previous recipes, all records in a list have been editable. This works well when the user is expecting to edit a number of records, but is not a great experience for users that predominantly view records. In this situation, it is better to give the user a read-only view of the records and a rapid way to edit a record if required.
In this recipe, we will create a Visualforce page that presents a list of contacts in read-only mode. The user may double-click on any field in order to edit the record details. Any changes to the contact records are stored locally, until the user chooses to save or discard them.
Standard Visualforce markup provides support for inline editing, but this requires each field to be double-clicked to edit individually.
This recipe makes use of a custom controller that must be present before the Visualforce page can be created.
Salesforce provides powerful analytic capabilities through the report and dashboard builders, but there are times when reporting requirements cannot be satisfied through the standard functionality; for example, where data from a number of different sources is required to be presented in multiple formats. In this scenario, Visualforce can give fine-grained control over the layout of the results, while a custom controller allows retrieval of any accessible data in the system.
In this recipe, we will create a Visualforce report that retrieves all cases matching criteria specified by the user and outputs these in a tabular format containing details of all cases, keeping a running total of the number of cases with the same status and origin. Two tables that provide the total count of cases for each status and origin value follow this.
In the previous recipes, all lists of records being managed by the page or related to the record being managed have been loaded synchronously; that is, the records have been retrieved by the controller and displayed when the page is initially loaded. In the event that the query retrieving the records is complex (and thus, time consuming), or where the payload for the records is large due to the volume of records or the size of each individual record, this can result in a delay before the page is loaded. A delay of this nature is invariably a negative experience for the user, often leading them to conclude that the application has failed in some way.
In this recipe, we will create a Visualforce page that loads an account record prior to rendering the page for the first time, and then loads the opportunity records associated with the account asynchronously. A spinning GIF is displayed to the user indicating that the asynchronous load is taking place.
© 2013 Packt Publishing Limited All Rights Reserved
