In this chapter, we will cover the following recipes:
Editing a record in Visualforce
Adding error messages to field inputs
Adding error messages to nonfield inputs
Using field sets
Adding a custom lookup to a form
Adding a custom datepicker to a form
Retrieving fields when a lookup is populated
Breaking up forms with action regions
The "Please wait" spinner
Avoiding validation errors with action regions
Action chaining
Errors – harmful if swallowed
Forms are a key feature of any application that makes use of Visualforce. They provide a mechanism to capture data entered by the user and send this to the page controller for processing, for example, to create, edit, or delete sObject records, or to send the user to a specific page.
Users enter data through input components. Visualforce provides a specific standard component, <apex:inputField />, for entering sObject field data. This component renders the appropriate device for entering data based on the field type, such as a JavaScript date picker for a field of type Date. Input components are bound to sObject fields or controller properties via the merge syntax. Controller properties that are public and have a public getter and setter may be bound to input components without writing any further code.
Processing of the submitted form is carried out via Action methods. These may be provided automatically by the platform in the case of standard controllers, or coded using...
The standard record edit page does not allow customization outside the layout of fields. Editing records with Visualforce pages allows customization of all aspects of the page, including styling, content, and displayed buttons.
In this recipe, we will create a Visualforce page that provides contact edit capability, but does not allow a contact to be reparented to a different account. The account lookup field is editable until the record is saved with the lookup populated, after which it becomes read-only. This page will also render a different section heading depending on whether the contact is being created or edited.
This recipe makes use of a standard controller, so we only need to create the Visualforce page.
When users are editing or creating a record via a Visualforce page, they will often make mistakes or enter invalid data. The required fields will present an error message underneath the field itself, but validation rules or exceptions will simply send the user to a new page with a large error message, telling them that the insert or update failed.
In this recipe we will create a Visualforce page to allow a user to create or edit a contact record. The contact standard controller and a controller extension manage the page. The extension controller checks whether the e-mail address or phone number field has been populated. If either of the fields is populated, the record will be saved, but if both are missing, an error message will be added to both fields asking the user to populate at least one of them.
This recipe makes use of a controller extension, so this will need to be created before the Visualforce page.
In the previous recipe, Adding error messages to field inputs, the platform took care of positioning of the error message based on whether the field had any errors associated with it. Visualforce automatically provides this functionality for <apex:inputField /> components, but if a different input component is used, such as <apex:inputText /> or <apex:selectList />, there is no equivalent functionality.
In this recipe we will create a Visualforce page to allow a user to create or edit a contact record. The contact standard controller and a controller extension manage the page. The ID of the account that the contact is associated with is entered via an <apex:selectList /> component, which is bound to a controller property rather than an sObject field. If the user does not select an account to associate the contact with, an error message is displayed under the <apex:selectList /> component.
A field set defines a group of sObject fields. A Visualforce page can iterate the fields contained in the set and access the values and other information, such as label or type, through the merge syntax. This decouples maintenance of the page from the skill set required to author Visualforce pages, and allows administrators to add or remove fields through point and click.
In this recipe we will create two field sets for the contact sObject: one to display the address information and another to display information about the contact. We will then create a Visualforce page that uses these field sets to render input components inside a page block section, which allow a contact record to be created or edited.
The Salesforce standard lookup functionality renders a dialog that supports a small amount of customization. The fields displayed may be configured, and if Enhanced Lookups have been enabled, the results can be filtered and ordered, and large result sets may be paged through. The lookup dialog's layout can neither be altered, nor can it be branded or contain additional help text.
In this recipe we will create a Visualforce lookup page that replaces the lookup dialog and provides additional instructions to the user. An additional Visualforce page will demonstrate how this can be be integrated into a custom opportunity create page.
The standard datepicker that is rendered when an <apex:inputField /> component is bound to an sObject field of type Date or DateTime has a limited range of years available, as shown in the following screenshot:
While this range of years may be suitable for opportunity close dates, it is unsuitable for capturing a contact's date of birth. One option to improve this is to add some JavaScript to the page that alters the datepicker year range, but this entails a risk as it relies on the standard datepicker code to remain the same.
In this recipe, we will integrate a third-party JavaScript datepicker with a Visualforce input field bound to a date. The datepicker used is from Design2Develop and can be downloaded from http://www.design2develop.com/calendar/. This has been chosen as the style class names; do not conflict with any standard Salesforce style classes as of the Summer 13 release of Salesforce.
When viewing an sObject that has a lookup relationship to another sObject, additional fields from the related sObject can be displayed on the page using formula fields. When creating a new record, or editing an existing record and changing the lookup value, formula fields cannot be used, as the lookup field has only been populated with a record ID and the related record has not been retrieved.
In this recipe, we will create a Visualforce page that allows a user to create a case sObject record. The case standard controller and a controller extension manage the new case record. When the lookup to the account that the case is related to is populated, additional fields are retrieved from the account record and displayed.
This recipe makes use of a controller extension, so this will need to be present before the Visualforce page can be created.
The submission of a form in a Visualforce page causes the view state and all user inputs to be processed by the controller. In the event that the form is being submitted back, purely to introduce some additional information based on a single user input, this can be inefficient, especially if there are a large number of field inputs on the page. The <apex:actionRegion /> component can be used to break the form up into discrete sections, reducing the amount of data processed by the controller and improving performance of the page.
In this recipe we will create a Visualforce page that allows a user to create a case record. The case subject is automatically generated by a controller extension from a base subject entered by the user and the name of the account that the case is associated with. A change to either the base subject or the account lookup causes the form to be submitted in order to update the generated subject. Each of these fields is contained...
When a user carries out an action that results in a Visualforce form submission, for example, clicking a button, it can be useful to render a visual indication that the submit is in progress. Without this a user may click on the button again, or assume there is a problem and navigate away from the page. The standard Visualforce <apex:actionStatus /> component can display messages when starting and stopping a request, but these messages are easily missed, especially if the user is looking at a different part of the page.
In this recipe, we will create a Visualforce page that allows a user to create a case sObject record utilizing the case standard controller. When the user clicks on the button to create the new record, a spinner GIF will be displayed. In order to ensure that we have the user's full attention, the page will be grayed out while the submit takes place.
Submitting a Visualforce form without populating a required field causes an error message to be returned to the user. When the user has triggered the submission by clicking on a button, a message of this nature will not come as a surprise. If the submission is automatically triggered, for example, to retrieve fields once a lookup is populated, the sudden and unexpected appearance of an error message is a poor user experience.
In this recipe we will create a Visualforce page to create an opportunity with a number of required fields. When the user selects the account to associate the opportunity with, the form will be submitted, and related fields from the account record populated regardless of whether the required fields have been populated.
This recipe makes use of a controller extension, so this will need to be created before the Visualforce page.
Action chaining allows multiple controller action methods to be executed in a series from a Visualforce page, each in a separate transaction. This technique is rarely used, but does solve the following problems:
Working around governor limits; for example, repeatedly polling an external system to determine if processing triggered through a web service call has completed without breaching the limit for callouts per transaction. In this case, the same action would be chained to poll the external system and then update the Visualforce page to indicate the user whether the action had completed.
Avoiding the MIXED_DML_OPERATION error when the controller must modify setup and nonsetup records; for example, changing a user and an opportunity record. In this case, the first action in the chain would modify the user record, while the second would modify the opportunity record.
In this recipe, we will create a Visualforce page to create an opportunity and move it through a number of stages...
When a form submission results in a rerender of a section rather than refreshing the entire Visualforce page, it is very easy to cause error messages from the controller to be swallowed rather than displayed to the user. In this situation, as far as the user is concerned, the form submission is broken; they click on a button and nothing on the page changes.
In this recipe we will create a Visualforce page to create an opportunity. When the account the opportunity is associated with is selected, the form will be submitted and the account record retrieved so that additional fields on the page may populated. If the opportunity name is not defined, the form submission will fail and an error message will be displayed to the user.
This recipe makes use of a controller extension, so this will need to be created before the Visualforce page.
© 2013 Packt Publishing Limited All Rights Reserved
