This document provides an overview of the Force.com user interface and its model-view-controller (MVC) architecture. It describes the key components of the MVC pattern used in Visualforce pages, including controllers, views, and view components. It also explains standard controllers, controller extensions, and custom controllers, as well as common view components for data, actions, and user interface styling.

1. Force.com User Interface
Sujit Kumar
Zenolocity LLC © 2012 - 2024

2. Overview
• MVC Architecture
• Hello World Example
• Controllers
• View Components
• Native UI
• Security

3. MVC Architecture
• View or Presentation – HTML with VisualForce
specific XML tags.
• Controller – Apex classes with business logic.
• Model (data read and write access) is part of
the Controller.

4. Visual Force MVC Architecture

5. Controllers
• Interaction of the controller with the UI is via
the variables and action methods.
• Action methods perform the processing work
on behalf of the user. Wired up to buttons,
links, and even asynchronous events on the
user interface.
• Variables exposed to the presentation layer
via getters and setters.

6. Types of Controllers
• Standard Controllers - replicate the behavior
of the native UI, such as editing and creating
records, but allow customization without
code.
• Controllers with Extensions – classes written
in Apex that add extend or override behavior
of standard controllers.
• Custom Controllers – implement from scratch.

7. VisualForce Page
• Defines the appearance of the UI using a mixture
of standard HTML and VisualForce-specific XML
markup.
• The XML markup is used to add view components
to the page.
• View components bind the controller to the page,
defining how data and user actions are to be
rendered in the user interface.
• Force.com provides a standard set of view
components to support common HTML UI
patterns and supports user-defined components.

8. Interaction between Page and
Controller
• In the MVC picture, the arrows between the page
and the controller represent expressions.
• Expressions are embedded in view components
to allow the page to reference methods in the
controller or in system classes such as UserInfo.
• Expressions in Visualforce use the same language
as formula fields in the database, with a special
prefix and suffix added.
• For example, {!save} is an expression that invokes
the save method of the controller.

9. Hello World Page
<apex:page controller="MyPageController">
<apex:form>
Your name: <apex:inputText value="{!name}" />
<apex:outputText value="{!message}" />
<apex:commandButton action="{!hello}"
value="Say Hi" />
</apex:form>
</apex:page>

10. Hello World MyPageController
public class MyPageController {
public String name { get; set; }
public String message { get; private set; }
public PageReference hello() {
message = 'Hello, ' + name;
return null;
}
}

11. Standard Controllers
• Every database object, both standard and
custom, has a standard controller.
• Its name is simply the name of the object.
• No Apex code exists for a standard controller.
• The controller implementation is already
provided by Force.com.
• By default, the standard controller operates on a
single record at a time. It receives this record
from the id parameter in the URL.

12. Expressions for Standard Controller
Following expressions are available in a page that uses a standard controller.
Data: {!id} is the unique identifier of the current record, and {!object} is the
current record itself, where object is the lowercase name of the object. All
fields of the object are automatically available, including related child objects
but not parent objects.
Navigation: {!cancel} navigates to the cancel page, {!edit} to the standard edit
page, and {!view} to the standard view page.
Action and Navigation: {!delete} deletes the current record and navigates to
the standard delete page, and {!save} saves the current record and refreshes
the page.
Action Only: {!quicksave} saves the current record without navigation.

13. Standard Set Controller
• Operates on a list of records rather than a
single record. The list is produced by executing
a view, a user-defined set of column names,
filter criteria, and sort criteria for an object.
<apex:page standardController="Proj__c
recordSetVar="projects">
<apex:repeat value="{!projects}" var="p">
{!p.Name}<br />
</apex:repeat>
</apex:page>

14. Standard Set Controller
• The recordSetVar indicates to Force.com that
the standard set controller should be used.
• Can work with up to 10,000 records at a time.
• Supports pagination with a variable page size.
It also supports multiple selection and actions
on a selected set of records.

15. • Data: The variable name you set in recordSetVar is bound to the current list of
records, {!selected} is an array of SObjects that are selected, {!resultsSize} sets or
gets the number of records currently displayed, and {!completeResult} is a Boolean
containing false if more than 10,000 records exist.
• Pagination: Navigate across multiple pages of data using the {!first}, {!last}, {!next},
and {!previous} actions. {!pageNumber} sets or gets the current page number, and
{!pageSize} sets or gets the number of records in a page. {!hasPrevious} returns true
if a previous page exists, {!hasNext} returns true if a subsequent page exists.
• Filters: {!filterId} is the unique identifier of the currently selected filter (list view),
and {!listViewOptions} is an array of SelectOption objects containing the names and
identifiers of the available list views.
• Navigation: {!cancel} navigates to the cancel page, and {!edit} to the standard edit
page.
• Action and Navigation: {!delete} deletes the current record and navigates to the
standard delete page, and {!save} saves the current record and refreshes the page.
• Action Only: {!quicksave} saves the current record without navigation.

16. Controller Extensions
• Extends or Overrides the behavior of a Standard or a Custom
Controller.
• Primarily used to integrate Visualforce more tightly with the native
user interface. Many features of Visualforce integration such as
overriding standard buttons are not supported for pages that use
custom controllers.
• Custom controllers can be easily retrofitted to become controller
extensions.
• Multiple extensions can be used in a single page, enabling a large
monolithic controller to be divided into smaller controllers by
behavior, where some pages might use only a subset of the
behaviors.

17. Controller Extensions (contd…)
• A controller extension is any Apex class containing a
constructor that takes a single argument of type
ApexPages.StandardController or
CustomControllerName, where CustomControllerName
is the name of a custom controller you want to extend.
• Multiple controller extensions can be defined for a
single page through a comma-separated list. This
allows for overrides of methods with the same name.
• Overrides are defined by whichever methods are
defined in the “leftmost” extension, or, the extension
that is first in the comma-separated list.

18. Example: Controller Extensions
• Controller with Extensions
public class MyPageController {
private ApexPages.StandardController controller;
public MyPageController(ApexPages.StandardController controller) {
this.controller = controller;
}
public PageReference doSomething() { return null; }
}
• Page Using Sample Controller Extension
<apex:page standardController="Resource__c“
extensions="MyPageController">
<apex:form>
<apex:commandButton action="{!doSomething}"
value="Do Something" />
</apex:form>
</apex:page>

19. Custom Controllers
• Provide complete control over the behavior of a
page with no default implementation.
• Simply an Apex class designed to be bound to a
Visualforce page. No new syntax to learn.
• Involves defining the data to make available to
the page and the actions that the page can
invoke.
• Page Components use expressions to bind data
exposed in the Controller. This binding is by
reference, so data can be modified in the page or
the Controller.

20. Example Custom Controller
public class MyPageController {
public Proj__c proj { get; private set; }
public MyPageController() {
proj = [ SELECT Name, Account__r.BillingCity
FROM Proj__c
WHERE Name = 'Tim Barr' LIMIT 1 ];
}
}

21. Expression Language
• Expression language allows traversal of an object
through dot notation, so providing separate getters
and setters for every field in a database record, for
example, is not necessary. Expose the object itself and
use dot notation to access its fields.
• you can combine expressions to form more complex
expressions. The expression {!isVisible && isEditable}
invokes both the getIsVisible and getIsEditable
methods on the controller and evaluates to true if they
are both true.
• Conditional expressions are also supported.

22. Action Methods
• Actions on a page are wired up to action methods in the controller, again
by expression language.
• Action methods are public, non-static controller methods.
• Return a PageReference object or null. If null, the current page is
refreshed. If not, the PageReference is used to determine the location of
the new page.
• Use the setRedirect method on a PageReference. A redirect updates the
browser’s URL, resets the view state and prevents problems with the
browser’s reload button.
• Perform custom business logic, like using DML methods to insert a record
to the database.

23. View Components
• View components work with the controller to
define the appearance and behavior of a
Visualforce user interface.
• They connect variables in the controller to input
and output elements such as text boxes and
labels, and methods in the controller to action-oriented
elements such as buttons and links.
• Force.com provides a library of standard view
components to support common Web user
interface design patterns.

24. Types of View Components
• Data Components – move data in/out of the controller
using HTML elements.
• Action Components - invoke methods on the controller,
updating the view state and refreshing the page or
navigating to a new page.
• Primitive Components – similar syntax to HTML elements.
• Force.com Styled Components – allow pages to inherit the
style of the native UI.
• Force.com UI Components - – allow pages to inherit the
style & behavior of the native UI – list Views, enhanced List
Views, related List views, detail views.
• Custom Components

25. View Components Basics
• View components are embedded in a Visualforce page
using XML markup.
• Every user interface page must begin with the page
component.
• All Visualforce components must be declared within
the page component.
• The rendered attribute, present on most components
allows conditional rendering of its HTML. It is a
boolean value that indicates whether the component is
included in the page. Setting rendered to false does not
hide the component using CSS. It omits it entirely from
the rendered page.

26. Example of a View Component
• The XML markup of a view component
consists of three parts: the component name,
an optional set of attributes, and an optional
component body.
<apex:dataList value="{!resources}" var="resource">
<b>{!resource.Name}</b>
</apex:dataList>

27. Page Definition
• Every Visualforce user interface page must
begin with the page component.
• Connect the page to a controller and
optionally override the global appearance of
the page.
• Requires either a standard (standardController
attribute) or a custom controller (controller
attribute) or a controller extension (via the
extensions attribute).

28. Page Definition Style
• By default, pages are styled consistently with
the Force.com native UI.
• include its stylesheet, sidebar, and header
region containing application tabs, banner,
and drop-down list of applications.
• Override this behavior by setting the
standardStylesheets, sidebar, and showHeader
Boolean attributes.

29. Data Components
• Allow DB fields and records to be manipulated within a Visualforce
page. 3 Types:
• Metadata-Aware Components: The HTML rendered by these smart
components varies based on the definition of the field. These
components are valid only when bound to database objects.
• Primitive Data Components: If field data is contained in a variable
in Apex code rather than a database object, use primitive data
components to render input and output HTML elements bound to
their values.
• Repeating Components: If you have a list of any type of object, you
can iterate over it with a repeating component to render its
contents.

30. Metadata-Aware Components
• 2 components: one for input (inputField) and
one for output (outputField).
• inputField must be within a Form component.
• For inputField, the html displayed depends on
the database field it is bound to.
• The outputField formats the value of a field
using the correct pattern for that field’s data
type.

31. Primitive Data Components
• Add Visualforce functionality to standard HTML
tags.
• Use these components when you are working
with data that is not contained in a database
object or when the standard Visualforce
rendering or behavior is not desirable.
• Except outputLabel, all components listed in the
table must be contained in a form component or
else compilation fails.
• Examples: inputText, selectList, selectRadio, etc.

32. Repeating Data Components
• Bound to a list of values, iterate over them,
rendering the component body for each child
in the collection.
• Attributes: value (collection) and var (current
child).
• 3 types: dataList (HTML List), dataTable (HTML
table) and repeat (no HTML, custom HTML
provided by developer).

33. Action Components
• Allow the page to invoke a method on the Controller.
The method on the controller typically issues a DML &
then refreshes the current page or navigates to a new
page.
• Setter methods on Controller used to inject data from
the page.
• 2 basic action components: commandButton and
commandLink.
• Valid only inside a Form Component.
• action attribute specifies the name of the controller
method to invoke or the URL of a new page to navigate
to.

34. Primitive Components
• Very similar to standard HTML tags but PCs can do
server side conditional rendering which standard HTML
cannot.
• Visualforce provides the rendered attribute, that
improves the performance of pages by conditionally
rendering markup based on the state of the controller.
• Additional Primitive Components: includeScript and
stylesheet. These 2 do not have the rendered attribute,
have a val attribute that specifies the URL of the script
or style sheet to load. More efficient & ensure scripts
and stylesheets are not duplicated on the page.

35. Force.com Styled Components
• Force.com’s native UI makes heavy use of CSS and
JavaScript within its Web pages to provide a
consistent look-and-feel across the platform.
• Many Visualforce components deliver this same
styling to developers, without requiring any
knowledge of Force.com’s CSS or other
implementation details.
• 5 Categories based on their function: Page
Structure, Action Containers, Table, Paging
Components, Notifications.

36. Force.com Styled Components -
Categories
• Page Structure: sectionHeader, pageBlock, pageBlockSection, and
pageBlockSectionItem are the native structural elements used by
Force.com to organize a page into a hierarchy of clearly identifiable
sections, subsections, and sets of label/field pairs.
• Action Containers: pageBlockButtons and toolbar / toolbarGroup organize
a series of buttons or links for performing actions on the page.
• Table: pageBlockTable is used like a dataTable but renders rows and
columns in the Force.com native style.
• Paging Components: panelBar / panelBarItem and tab / tabPanel group
components into pages that can be dynamically shown and hidden.
• Notifications: pageMessages displays errors and information.

37. Force.com UI Components
• listViews: rendered by Force.com on the list page
of an object tab when the Enable Enhanced Lists
option is disabled for the organization.
• enhancedList: consists of a drop-down list of view
names and a table of records returned by
executing the view.
• relatedList: renders the records of any one of an
object’s child objects.
• detail: provides a subset of the native user
interface’s detail page for an object.

38. listViews Component
• Capability to create and edit list views, as well
as execute them and render their records.
• The only required attribute of listViews is
type, which binds a database object type to
the component.

39. enhancedList Component
• Enhanced version of the listViews component.
• Same functionality but also includes drag-and-drop
re-orderable columns, sortable columns,
and results pagination with dynamic page
sizes.
• Appears in the native UI only when Enable
Enhanced Lists is enabled for the organization.
• Required attributes: height and (type of the
DB object or the listId of the listView).

40. relatedList Component
• Renders a list of paginated child records.
• Allows related records to be edited, deleted, and
created, depending on the object permissions of
the current user.
• Required attributes: list (the name of the child
relationship to be rendered in the list) and
subject (an expression language reference to the
parent record on the controller , defaults to the id
parameter of the page if not provided).
• Both MDRs and LRs are supported.

41. Detail Component
• Replicates the functionality of the native UI on
the detail page of a record. It respects the page
layout of the record, including page layouts
defined per record type.
• It also supports inline editing for the edit mode of
an object.
• Requires a subject or it attempts to read a record
identifier from the page’s id URL parameter.
• By default, all related lists are rendered below the
detail section unless the relatedList parameter is
set to false.

42. Extensible UI Elements
• The following are extensible using Visualforce.
• Standard Pages
• Standard Buttons
• Page Layouts
• Custom Buttons and Links
• Custom Tabs

43. Extensible UI Elements
• Standard Pages: default UI for maintaining the records.
Can be overridden with Custom Visualforce pages.
• Standard Buttons: navigate the user to standard pages.
Can be remapped to navigate the user to custom
pages.
• Custom Buttons: appear at the top and bottom of
standard pages.
• Custom Links: appear in a detail page.
• Custom Tabs: added to an application and appear at
the top under the application banner. A Visualforce
page can be configured as a custom tab.

44. Standard Pages
• 4 standard pages for working with DB records.
• Tab Page: appears when a custom object tab
is clicked. Shows recently accessed records.
• List Page: shows records in a list. Reach this
page by clicking Go button on the tab page.
• View Page: read-only view of a single record
and it’s related records.
• Edit Page: same layout as the view page but
lets you change and save the record.

45. Overriding Standard Pages
• Tab, view, and edit pages can be overridden
only with Visualforce pages that use a
standard, single record controller.
• The list page must use a standard set
controller.
• Controller extensions are supported in all
pages.

46. Overriding Standard Buttons
• 4 buttons can be overridden.
• New – navigates to edit page of a new record.
• Delete – page navigated to after record is
deleted. Default is the list page.
• Clone -> to edit page of a duplicated record.
• Accept – applies to records owned by a queue
rather than a single user. Enables to transfer
ownership to the user. Appears on a list page
when displaying records owned by a queue.

47. Overriding Page Layouts
• A Visualforce page can be embedded in an
object’s page layout alongside its fields.
• For Visualforce pages to appear in the page
layout editor, they cannot already be in use by
a tab and must use a standard single record
controller, with or without extensions.

48. Custom Buttons and Links
• They can navigate to any VF page.
• Can be added to page layouts.
• Need to be defined on the database object.
• Go to App Setup area, click Create -> Objects,
and then click the object. Scroll to the Custom
Buttons and Links area and click the New
button.
• Can be added to the detail page layout or
related list page layout.

49. Custom Tab
• You can configure any Visualforce page as a
new tab in the Force.com native UI.
• To add a new Visualforce tab, go to the App
Setup area and click Create ->Tabs.
• Click the New button in the Visualforce Tabs
section to create a tab.
• Select a Visualforce page, select a tab label
and style, set tab visibility on profiles and
applications, and click Save.

50. Debugging and Tuning
• Look at the System log first.
• Add System.debug statements in controller.
• Trial & Error – comment out portions of VF page
till you can narrow the error.
• Use Firebug to find client side errors.
• View State is limited to 128k. View State contains
the local variables in the controller.
• Reduce local variables and/or mark some of them
as transient.

51. Visualforce Security
• Obeys the object and field level security
configured in profiles.
• Access to the page itself is granted by user’s
profile.
• Record security handled by controller through
special keywords in Apex.

52. Developer Notes – VF Security
• When developing a controller, check that the
SOQL, SOSL, and DML operations are fully
compatible with the set of profiles expected to
use the page.
• A developer has full visibility to every object and
field, but do not assume that other users have
the same level of access. Test the Visualforce
pages by logging in as a test user or cycling
through profiles on a single test user.
• Write unit tests that run under the privileges of a
specific user using the System.runAs method.

53. Record Level Security
• Standard controllers always honor the record-level
security of the current user.
• Record sharing rules are ignored by code in
custom controllers. These controllers run in a
system context, like a trigger.
• Record sharing rules are honored by the
methods of standard controllers that have
extensions defined, but the code in an
extension class itself still runs in system mode.

54. Record Sharing – Custom Controllers
• Two security modes are available: with
sharing and without sharing.
• Without Sharing is default mode.
• Example of with sharing:
public with sharing class MyController {
// the code in this controller honors record sharing rules
}

55. Page Level Security
• Pages must be explicitly enabled for each profile that
requires access. If this is not done, users will receive an
error page titled Insufficient Privileges when attempting to
view the page.
• To grant a profile access to a page, go to the Administration
Setup and click Manage Users ➝ Profiles. Scroll to the
Enabled Visualforce Page Access section and click the Edit
button. Select pages from the Available Visualforce Pages
list and click the Add button to add them to the Enabled
Visualforce Pages list. Click Save.
• Users with the Customize Application permission can
access all Visualforce pages in the organization.

56. Uncaught Exceptions
• In triggers, good formatted message is shown.
• In VF page, generic error page whose appearance
cannot be controlled or customized.
• Goals of error handling in VF pages – avoid
uncaught exceptions.
• Place a try/catch block around every action
method, or at least those that perform SOSL,
SOQL, or DML operations.
• Catch all exceptions and rollback the transaction
using a savepoint in the controller method.

57. Error Communication
• VF provides page components and corresponding data objects for
communicating errors to the user in a consistent way.
• The page components are messages and pageMessages, which
display the page-level errors returned by a controller.
• These components are placed on pages, typically at the top, and
render the ApexPages.Message objects added to the page.
• Message objects contain a message and optional severity.
• Severity is used to style the message when displayed in the
pageMessages component and can also be filtered on in test
methods.
• Example of code to add an error-severity message to the page. To
be visible, it must be rendered by a messages or pageMessages
component.
ApexPages.addMessage(new ApexPages.Message(
ApexPages.Severity.ERROR, 'Something went wrong'));

58. Governor Limits
• Apply during execution of user-initiated actions and are
not cumulative. When an action is complete, the
governor limits reset.
• Heap => 3MB.
• Apex code => 200,000 lines of code executed.
• SOQL => 100 queries.
• Records from SOQL => 50,000 records cumulatively for
all SOQL queries.
• DML => 150 DML statements.
• Records in DML => 10,000 records cumulatively for all
DML statements.