Salesforce Basics - Visualforce

Visualforce is a component-based user interface framework for the Salesforce platform. Visualforce gives you a lot more control over the user interface by providing a view framework that includes a tag-based markup language similar to HTML, a library of reusable components that can be extended, and an Apex-based controller model. Visualforce supports the Model-View-Controller (MVC) style of user interface design, and is highly flexible.
You want your Warehouse app to look slick, so you're going to use a custom stylesheet (CSS file) to specify the color, font, and arrangement of text on your page. Most Web pages and Web designers use CSS, a standard Web technology, for this purpose, so we've created one for you. In order for your pages to reference a stylesheet, you have to upload it as a static resource. A static resource is a file or collection of files that is stored on Salesforce. Once your stylesheet is added as a static resource, it can be referenced by any of your Visualforce pages.
• $Resource is a global variable accessible in Visualforce pages. With $Resource.styles, you refer to the resource called "styles" that you created earlier.
• The URLFOR() function locates the static resource, and a file within that resource, and calculates the URL that should be generated in your final page. If the syntax looks familiar, it's because you've already encountered it to dynamically evaluate values when the Visualforce page is rendered.
• Why did you download a .zip file for only one small stylesheet? Usually stylesheets (and other static references) come in bundles of more than one, and so it's useful to see the code that accesses a .zip file. If you had simply uploaded styles.css you could refer to it using <apex:stylesheet value="{$Resource.styles}" />. While that code is simpler, you wouldn't know how to refer to files in an archive. After the stylesheet is uploaded as a .zip file in a static resource, all you need to do is enter the name of the stylesheet between single quotes: <apex:stylesheet value="{!URLFOR($Resource.styles, 'enter_stylesheet_name.css')}" />.
Visualforce's Model-View-Controller design pattern makes it easy to separate the view and its styling from the underlying database and logic. In MVC, the view (the Visualforce page) interacts with a controller. In our case, the controller is usually an Apex class, which exposes some functionality to the page. For example, the controller may contain the logic that should be executed when a button is clicked. A controller also typically interacts with the model (the database)—exposing data that the view might want to display.
All Salesforce objects have default standard controllers that can be used to interact with the data associated with the object, so in many cases you don't need to write the code for the controller yourself. You can extend the standard controllers to add new functionality or create custom controllers from scratch.
• Setting the standardController attribute connects your page to the standard controller for a specific object, in this case, the Merchandise__c object.
• Setting the recordSetVar attribute puts a standard controller into "list" mode and sets a products variable, which will contain the list of merchandise records.
<apex:dataTable value="{!products}" var="pitem" rowClasses="odd,even">
The value attribute indicates which list of items the dataTable component should iterate over. The var attribute assigns each item of that list, for one single iteration, to the pvitem variable. The rowClasses attribute assigns CSS styling names to alternate rows.

<apex:page standardStylesheets="false" showHeader="false" sidebar="false" standardController="Merchandise__c" recordSetVar="products">

  <apex:stylesheet value="{!URLFOR($Resource.styles_warehouse, 'styles.css')}"/>

  <h1>Inventory Count Sheet</h1>

  <apex:form >
      <apex:dataTable value="{!products}" var="pitem" rowClasses="odd,even">
          <apex:column headerValue="Product">
              <apex:outputText value="{!pitem.name}"/>
          </apex:column>
          <apex:column headerValue="Inventory">
              <apex:outputField value="{!pitem.Quantity__c}"/>
          </apex:column>
          <apex:column headerValue="Physical Count">
              <apex:inputField value="{!pitem.Quantity__c}"/>
          </apex:column>
      </apex:dataTable>
  </apex:form>
</apex:page>

The headerValue attribute has simply provided a header title for the column, and below it you'll see a list of rows: one for each merchandise record. The expression {!pitem.name} indicates that we want to display the name field of the current row.

The dataTable component produces a table with rows, and each row is found by iterating over a list. The standard controller you used for this page was set to Merchandise__c, and the recordSetVar to products. As a result, the controller automatically populated the products list variable with merchandise records retrieved from the database. It's this list that the dataTable component uses.

• You need a way to reference the current row as you iterate over the list. That statement var="pitem" assigns a variable called pitem that holds the current row.

• Every standard controller has various methods that exist for all Salesforce objects. The commandButton component displays the button, and invokes a method called quicksave on the standard controller, which updates the values on the records. Here, you're updating the physical count of the product and performing a quick save, which updates the product with the new count.

• Although pagination isn't shown in this example, the functionality is there. If you have enough records to page through them, add the following code below the commandButton for page-flipping action.

<apex:commandLink action="{!next}" value="Next" rendered="{!hasNext}" />

<apex:page standardStylesheets="false" showHeader="false" sidebar="false" standardController="Merchandise__c" recordSetVar="products">

  <apex:stylesheet value="{!URLFOR($Resource.styles_warehouse, 'styles.css')}"/>

  <h1>Inventory Count Sheet</h1>

  <apex:form >

      <apex:dataTable value="{!products}" var="pitem" rowClasses="odd,even">

          <apex:column headerValue="Product">

              <apex:outputText value="{!pitem.name}"/>

          </apex:column>

          <apex:column headerValue="Inventory">

              <apex:outputField value="{!pitem.Quantity__c}">

                  <apex:inlineEditSupport event="ondblclick" showOnEdit="update"/>

              </apex:outputField>

          </apex:column>

      </apex:dataTable>

      <br/>

      <apex:commandButton id="update" action="{!quicksave}" value="Update Counts" styleclass="updateButton"/>

  </apex:form>

</apex:page>

• The event attribute of the inlineEditSupport component is set to "ondblclick", which is a DOM event and means that the output field will be made editable when you double-click it. Also, the showOnEdit attribute causes the Update Counts button to appear on the page during an inline edit. This attribute is set to the ID of the Update Counts button.

• The Update Counts button is hidden through its style specification in the static resource file styles.css. The styleclass attribute on commandButton links this button to an entry in styles.css.

Order of Execution in Visualforce
When a user views a Visualforce page, instances of the controller, extensions, and components associated with the page are created by the server. The order in which these elements are executed can affect how the page is displayed to the user.

To fully understand the order of execution of elements on a Visualforce page, you must first understand the page's lifecycle–that is, how the page is created and destroyed during the course of a user session. The lifecycle of a page is determined not just by the content of the page, but also by how the page was requested. There are two types of Visualforce page requests:
> A get request is an initial request for a page either made when a user enters an URL or when a link or button is clicked that takes the user to a new page.
> A postback request is made when user interaction requires a page update, such as when a user clicks on a Save button and triggers a save action.

Order of Execution for Visualforce Page Get Requests
A get request is an initial request for a page either made when a user enters an URL or when a link or button is clicked that takes the user to a new page. The following diagram shows how a Visualforce page interacts with a controller extension or a custom controller class during a get request:

A diagram of how a Visualforce page interacts with a controller extention or a custom controller class during a get request.

In the diagram above the user initially requests a page, either by entering a URL or clicking a link or button. This initial page request is called the get request.

The constructor methods on the associated custom controller or controller extension classes are called, instantiating the controller objects.

If the page contains any custom components, they are created and the constructor methods on any associated custom controllers or controller extensions are executed. If attributes are set on the custom component using expressions, the expressions are evaluated after the constructors are evaluated.

The page then executes any assignTo attributes on any custom components on the page. After the assignTo methods are executed, expressions are evaluated, the action attribute on the <apex:page> component is evaluated, and all other method calls, such as getting or setting a property value, are made.

If the page contains an <apex:form> component, all of the information necessary to maintain the state of the database between page requests is saved as an encrypted view state. The view state is updated whenever the page is updated.

The resulting HTML is sent to the browser. If there are any client-side technologies on the page, such as JavaScript, the browser executes them.

As the user interacts with the page, the page contacts the controller objects as required to execute action, getter, and setter methods.

Once a new get request is made by the user, the view state and controller objects are deleted.

Note

If the user is redirected to a page that uses the same controller and the same or a proper subset of controller extensions, a postback request is made. When a postback request is made, the view state is maintained.

If the user interaction requires a page update, such as when the user clicks a Save button that triggers a save action, a postback request is made. For more information on postback requests, see Order of Execution for Visualforce Page Postback Requests.

For a specific example of a get request, see Examples of Visualforce Page Execution Order.

Order of Execution for Visualforce Page Postback Requests

A postback request is made when user interaction requires a page update, such as when a user clicks on a Save button and triggers a save action. The following diagram shows how a Visualforce page interacts with a controller extension or a custom controller class during a postback request:

1) During a postback request, the view state is decoded and used as the basis for updating the values on the page.
Note
A component with the immediate attribute set to true bypasses this phase of the request. In other words, the action executes, but no validation is performed on the inputs and no data changes on the page.

2) After the view state is decoded, expressions are evaluated and set methods on the controller and any controller extensions, including set methods in controllers defined for custom components, are executed.
These method calls do not update the data unless all methods are executed successfully. For example, if one of the methods updates a property and the update is not valid due to validation rules or an incorrect data type, the data is not updated and the page redisplays with the appropriate error messages.

3) The action that triggered the postback request is executed. If that action completes successfully, the data is updated. If the postback request returns the user to the same page, the view state is updated.
Note
The action attribute on the <apex:page> component is not evaluated during a postback request. It is only evaluated during a get request.

4) The resulting HTML is sent to the browser.
If the postback request indicates a page redirect and the redirect is to a page that uses the same controller and a proper subset of controller extensions of the originating page, a postback request is executed for that page. Otherwise, a get request is executed for the page. If the postback request contains an <apex:form> component, only the ID query parameter on a postback request is returned.

Tip
You can use the setRedirect attribute on a pageReference to control whether a postback or get request is executed. If setRedirect is set to true, a get request is executed. Setting it to false does not ignore the restriction that a postback request will be executed if and only if the target uses the same controller and a proper subset of extensions. If setRedirect is set to false, and the target does not meet those requirements, a get request will be made.

Once the user is redirected to another page, the view state and controller objects are deleted.

For a specific example of a postback request, see Examples of Visualforce Page Execution Order.

Salesforce Basics - Apex Triggers

A trigger can fire before or after DML operations.

Triggers have special variables accessible to them called context variables. In a nutshell, old and new context variables provide copies of old and new sObjects being updated by the call that fires the trigger. As you can see in the code, context variables are handy to scope processing in a trigger body.

In the FOR loop for Invoice Object for example, the trigger simply adds a validation error to any Invoice that has Line Items, which in turn causes the Force.com platform to roll back the transaction that fires the trigger (in this case, delete).

Apex can be invoked through the use of triggers. A trigger is Apex code that executes before or after the following types of operations:

insert
update
delete
merge
upsert
undelete

For example, you can have a trigger run before an object's records are inserted into the database, after records have been deleted, or even after a record is restored from the Recycle Bin.
You can define triggers for top-level standard objects that support triggers, such as a Contact or an Account, some standard child objects, such as a CaseComment, and custom objects.

For case comments, from Setup, click Customize | Cases | Case Comments | Triggers.
For email messages, from Setup, click Customize | Cases | Email Messages | Triggers.

There are two types of triggers:
Before triggers are used to update or validate record values before they’re saved to the database.
After triggers are used to access field values that are set by the system (such as a record's Id or LastModifiedDate field), and to effect changes in other records, such as logging into an audit table or firing asynchronous events with a queue. The records that fire the after trigger are read-only.

Triggers can also modify other records of the same type as the records that initially fired the trigger. For example, if a trigger fires after an update of contact A, the trigger can also modify contacts B, C, and D. Because triggers can cause other records to change, and because these changes can, in turn, fire more triggers, the Apex runtime engine considers all such operations a single unit of work and sets limits on the number of operations that can be performed to prevent infinite recursion. See Understanding Execution Governors and Limits.
Additionally, if you update or delete a record in its before trigger, or delete a record in its after trigger, you will receive a runtime error. This includes both direct and indirect operations. For example, if you update account A, and the before update trigger of account A inserts contact B, and the after insert trigger of contact B queries for account A and updates it using the DML update statement or database method, then you are indirectly updating account A in its before trigger, and you will receive a runtime error.

Implementation Considerations
Before creating triggers, consider the following:
upsert triggers fire both before and after insert or before and after update triggers as appropriate.
merge triggers fire both before and after delete triggers for the losing records and before update triggers for the winning record only. See Triggers and Merge Statements.
Triggers that execute after a record has been undeleted only work with specific objects. See Triggers and Recovered Records.
Field history is not recorded until the end of a trigger. If you query field history in a trigger, you will not see any history for the current transaction.
For Apex saved using Salesforce API version 20.0 or earlier, if an API call causes a trigger to fire, the chunk of 200 records to process is further split into chunks of 100 records. For Apex saved using Salesforce API version 21.0 and later, no further splits of API chunks occur. Note that static variable values are reset between API batches, but governor limits are not. Do not use static variables to track state information between API batches.

Order Of Execution Trigger events
UPSERT: Loads the original record from the database or initializes the record for an upsert statement.

UPDATE: If the record was updated with workflow field updates, fires before update triggers and after update triggers one more time (and only one more time), in addition to standard validations. Custom validation rules are not run again.

Triggers and Order of Execution
When you save a record with an insert, update, or upsert statement, Salesforce performs the following events in order.
Note
Before Salesforce executes these events on the server, the browser runs JavaScript validation if the record contains any dependent picklist fields. The validation limits each dependent picklist field to its available values. No other validation occurs on the client side.

On the server, Salesforce:
1) Loads the original record from the database or initializes the record for an upsert statement.
2) Loads the new record field values from the request and overwrites the old values.
If the request came from a standard UI edit page, Salesforce runs system validation to check the record for:
> Compliance with layout-specific rules
> Required values at the layout level and field-definition level
> Valid field formats
> Maximum field length
When the request comes from other sources, such as an Apex application or a SOAP API call, Salesforce validates only the foreign keys. Prior to executing a trigger, Salesforce verifies that any custom foreign keys do not refer to the object itself.
Salesforce runs user-defined validation rules if multiline items were created, such as quote line items and opportunity line items.
3) Executes all before triggers.
4) Runs most system validation steps again, such as verifying that all required fields have a non-null value, and runs any user-defined validation rules. The only system validation that Salesforce doesn't run a second time (when the request comes from a standard UI edit page) is the enforcement of layout-specific rules.
5) Executes duplicate rules. If the duplicate rule identifies the record as a duplicate and uses the block action, the record is not saved and no further steps, such as after triggers and workflow rules, are taken.
6) Saves the record to the database, but doesn't commit yet.
7) Executes all after triggers.
8) Executes assignment rules.
9) Executes auto-response rules.
10) Executes workflow rules.
11) If there are workflow field updates, updates the record again.
12) If the record was updated with workflow field updates, fires before update triggers and after update triggers one more time (and only one more time), in addition to standard validations. Custom validation rules and duplicate rules are not run again.
13) Executes processes.
If there are workflow flow triggers, executes the flows.
The Process Builder has superseded flow trigger workflow actions, formerly available in a pilot program. Organizations that are using flow trigger workflow actions can continue to create and edit them, but flow trigger workflow actions aren’t available for new organizations.
14) Executes escalation rules.
15) Executes entitlement rules.
16) If the record contains a roll-up summary field or is part of a cross-object workflow, performs calculations and updates the roll-up summary field in the parent record. Parent record goes through save procedure.
17) If the parent record is updated, and a grandparent record contains a roll-up summary field or is part of a cross-object workflow, performs calculations and updates the roll-up summary field in the grandparent record. Grandparent record goes through save procedure.
18) Executes Criteria Based Sharing evaluation.
19) Commits all DML operations to the database.
20) Executes post-commit logic, such as sending email.

During a recursive save, Salesforce skips steps 8 (assignment rules) through 17 (roll-up summary field in the grandparent record).

Additional Considerations
Please note the following when working with triggers.

> The order of execution isn’t guaranteed when having multiple triggers for the same object due to the same event. For example, if you have two before insert triggers for Case, and a new Case record is inserted that fires the two triggers, the order in which these triggers fire isn’t guaranteed.
> When a DML call is made with partial success allowed, more than one attempt can be made to save the successful records if the initial attempt results in errors for some records. For example, an error can occur for a record when a user-validation rule fails. Triggers are fired during the first attempt and are fired again during subsequent attempts. Because these trigger invocations are part of the same transaction, static class variables that are accessed by the trigger aren't reset. DML calls allow partial success when you set the allOrNone parameter of a Database DML method to false or when you call the SOAP API with default settings. For more details, see Bulk DML Exception Handling.
> If you are using before triggers to set Stage and Forecast Category for an opportunity record, the behavior is as follows:
        > If you set Stage and Forecast Category, the opportunity record contains those exact values.
        > If you set Stage but not Forecast Category, the Forecast Category value on the opportunity record defaults to the one associated with trigger Stage.
        > If you reset Stage to a value specified in an API call or incoming from the user interface, the Forecast Category value should also come from the API call or user interface. If no value for Forecast Category is specified and the incoming Stage is different than the trigger Stage, the Forecast Category defaults to the one associated with trigger Stage. If the trigger Stage and incoming Stage are the same, the Forecast Category is not defaulted.
> If you are cloning an opportunity with products, the following events occur in order:
         1. The parent opportunity is saved according to the list of events shown above.
         2. The opportunity products are saved according to the list of events shown above.
Note
If errors occur on an opportunity product, you must return to the opportunity and fix the errors before cloning.
If any opportunity products contain unique custom fields, you must null them out before cloning the opportunity.

> Trigger.old contains a version of the objects before the specific update that fired the trigger. However, there is an exception. When a record is updated and subsequently triggers a workflow rule field update, Trigger.old in the last update trigger won’t contain the version of the object immediately prior to the workflow update, but the object before the initial update was made. For example, suppose an existing record has a number field with an initial value of 1. A user updates this field to 10, and a workflow rule field update fires and increments it to 11. In the update trigger that fires after the workflow field update, the field value of the object obtained from Trigger.old is the original value of 1, rather than 10, as would typically be the case.

Salesforce Basics - Triggers and Order of Execution

When a record is saved with an insert, update, or upsert statement, the following events occur in order:

1. The original record is loaded from the database (or initialized for an insert statement)
2. The new record field values are loaded from the request and overwrite the old values
3. All before triggers execute
4. System validation occurs, such as verifying that all required fields have a non-null value, and running any user-defined validation rules
5. The record is saved to the database, but not yet committed
6. All after triggers execute
7. Assignment rules execute
8. Auto-response rules execute
9. Workflow rules execute
10. If there are workflow field updates, the record is updated again
11. If the record was updated with workflow field updates, before and after triggers fire one more time (and only one more time)
12. Escalation rules execute
13. All DML operations are committed to the database
14. Post-commit logic executes, such as sending email

Coding Standards:
Apex is Case-Insensitive. A good practice is for class names to start with an uppercase letter and method names to start with a lowercase letter.