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.
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:
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.
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:
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.
No comments:
Post a Comment