VisualForce

Visualforce is the new markup language in salesforce by using which we can render the standard styles of salesforce.we can still use HTML here in visualforce.Each visualforce tag always begins with "Apex" namespace.All the design part can be acoplished  by using Visualforce markup language and business part can be written in custom controllers associated with the page.

Creating Visualforce Pages:
You can create Visualforce pages either by using Visualforce development mode, or by creating pages in Setup.

To create a page using Visualforce developer mode:

1. In your browser, enter a URL in the following form: https://mySalesforceInstance/apex/nameOfNewPage, where the value of mySalesforceInstance is the host name of your Salesforceinstance (for example, na3.salesforce.com) and the value of nameOfNewPage is the value you want to give to the Name field on your page definition.
   For example, if you want to create a page called “HelloWorld” and your Salesforce organization uses the na3.salesforce.com instance, enterhttps://na3.salesforce.com/apex/HelloWorld.
   1. Because the page does not yet exist, you are directed to an intermediary page from which you can create your new page. Click Create page nameOfNewPage to create the new page. Both the pageName and Label are assigned the nameOfNewPage value you specified in the URL.

   To create pages in Setup:
   

   1. Click Your Name | Setup | Develop | Pages.
   2. Click New.
   3. In the Name text box, enter the text that should appear in the URL as the page name. This name can contain only underscores and alphanumeric characters, and must be unique in your organization. It must begin with a letter, not include spaces, not end with an underscore, and not contain two consecutive underscores.
   4. In the Label text box, enter the text that should be used to identify the page in Setup tools, such as when defining custom tabs, or overriding standard buttons.
   5. In the Body text box, enter Visualforce markup for the page. A single page can hold up to 1 MB of text, or approximately 1,000,000 characters.
   6. Click Version Settings to specify the version of Visualforce and the API used with this page. If your organization has installed managed packages from the AppExchange, you can also specify which version of each managed package to use. Generally, you should use the default values for all versions. This associates the page with the most recent version of Visualforce and the API, as well as each managed package. You can specify an older version of Visualforce and the API to maintain specific behavior. You can specify an older version of a managed package if you want to access package components or functionality that differs from the most recent package version.
   7. Click Save to save your changes and return to the Visualforce detail screen, or click Quick Save to save your changes and continue editing your page. Your Visualforce markup must be valid before you can save your page.

Once your page has been created, you can access it using a URL in the following form: http://mySalesforceInstance/apex/nameOfNewPage, where the value of mySalesforceInstance is the host name of your Salesforce instance (for example, na3.salesforce.com) and the value of nameOfNewPage is the value of the Name field on your page definition.



VISUALFORCE ARCHITECTURE:
A developer creates Visualforce pages by composing components, HTML, and optional styling elements on the Force.com platform. Just like HTML, Visualforce can integrate with any standard web technology or JavaScript framework to allow for a more animated and rich user interface. Each page is then accessible by a unique URL. When someone accesses a page, the server renders the page.

As the figure above illustrates, pages are constructed on the server and depending on the logic behind the page may interact with the database, invoke external web service calls, or both, before returning the view to the client (browser). In fact:

• Visualforce pages can react differently to different client browsers such as those on a mobile or touch screen device.
• Everything runs on the server, so no additional client-side callbacks are needed to render a complete view.
• Optional server-side call outs can be made to any Web service.

MVC MODEL

A simple example should give you a feel for Visualforce. Here's the code for a Visualforce page:

01	<apex:page standardController="Account">

02	<apex:form>

03	<apex:pageBlock title="Edit Account for {!$User.FirstName}">

04	<apex:pageMessages/>

05	<apex:pageBlockButtons>

06	<apex:commandButton value="Save" action="{!save}"/>

07	</apex:pageBlockButtons>

08	<apex:pageBlockSection>

09	<apex:inputField value="{!account.name}"/>

10	</apex:pageBlockSection>

11	</apex:pageBlock>

12	</apex:form>

13	</apex:page>

• The page component wraps every Visualforce page, and its standardController attribute lets us make use of standard, automatically-generated, controller technology.
• The pageBlock, pageBlockButtons and pageBlockSection tags provide standard Salesforce styling for a section in a page, similar to what you see on a detail page.
• The inputField generates an appropriate input element, depending on the type of the field.
• The commandButton renders a button, which when pushed, invokes a standard method called save() on the controller.

When you visit the page with your browser, the platform renders it, producing something like the following:

There are some important aspects to this page:

• The Account standard controller retrieved a record from the database considering the record Id found in the request (i.e., the URL), and made it available to the Visualforce page automatically.
• The $User variable provides access to details of the currently logged-in user.
• The {!account.name} expression retrieved the metadata associated with the name field of the Account object, rendered an appropriate input element, and initialized with the value from the Account retrieved from the database.
• The label for the name field on Account is automatically displayed, and the input is highlighted as required by virtue of theinputField component having been nested within a pageBlockSection.
• The save() method on the controller provides a means of persisting the object back to the database. Had there not been a record in the request, this same action would attempt an insert of the account information provided in the form.
• Any errors that occur in the submission of the form, either standard or custom, will be displayed by the pageMessages component.

The ease with which you can create powerful user interfaces that are tightly bound with the metadata, database, and controller layer is a key aspect of Visualforce. The following sections examine much of the functionality behind Visualforce.

The Model, View, Controller Paradigm

Visualforce pages are rendered on the server, and displayed on a client, typically a web browser. As such, they have server-side access to data and logic. Modern platforms will separate the database, model, and view out into separate layers. This gives you modularity, clear separation of concerns, and containment — ultimately making your application easier to code and maintain.

The following figure highlights the primary elements that comprise the capabilities of Visualforce as they pertain to the various layers of the MVC pattern illustrated in the following diagram.

In the figure:

• The model, or data structure, can be defined as either sObjects (the entity definitions for persisted data) or classes in Apex.
• The view, or presentation layer, is comprised of Pages and components as described above.
• The controller, or logic layer, includes any custom controller logic written in Apex, or standard behavior generated by the Force.com platform for each business entity.

The following figure shows the MVC layers in action with Visualforce:

Notice the following:

• The view, which is defined as our page defined above, containing the apex:inputField component.
• The apex:inputField component is bound through the expression on its value attribute to the controller's get method on its account property.
• The account property provides the view with the Account business entity object, the model in this example.

From the above diagram, the Account Name field presented in the page was rendered by inclusion of the apex:inputFieldVisualforce component. The value was derived through that component's value attribute expression, which calls into the controller layer for the get method on the controller's account property. Both the page and the controller are aware of the data structure and can interact with it directly — in this case the Account entity definition. As you can see, the expression uses simple dot notation to refer to the name field on the specific account instance.

For a full description of the database, and to Apex, the language used to code custom controllers, see An Introduction to the Force.com Database and An Introduction to Force.com Apex Code respectively. While the rest of this article may use both database and Apex functionality, it assumes you are familiar with these technologies.

Controllers and Extensions

Controllers and extensions provide the logic interaction and behavior for an application. Force.com provides standard controllers for all standard and custom business entities. These controllers provide access to standard platform behavior including saving, logic, and navigation. In the example above, the standard controller for account was specified so standard action methods such as save can be bound to action supporting components, such as apex:commandButton.

This is the signature for the save action method in the standard controller:

1	public PageReference save() {}

Clicking the button invokes the standard save process. Navigation is managed through the PageReference object that is returned from the method.

Custom controllers, written in Apex, deliver the flexibility to define your own logic, navigation, algorithms, and database and web services interactivity. With the stateful programming model provided by Visualforce, custom controllers can maintain state between pages making development of wizards straightforward. Custom controllers can themselves leverage the standard controller.

Assume that you have two database objects, Account and Contact. A simple controller class for a two step wizard that creates an Account and a related Contact might be defined as such:

01	public class MyWizardController {

02

03	public Account account { get; set; }

04	public Contact contact { get; set; }

05

06	public MyWizardController() {

07	account = new Account();

08	contact = new Contact();

09

}

10

11	public PageReference next() {

12	return Page.step2;

13

}

14

15	public PageReference previous() {

16	return Page.step1;

17

}

18

19	public PageReference save() {

20	Database.insert(account);

21	contact.accountId = account.id;

22	ApexPages.StandardController contactController = new ApexPages.StandardController(contact);

23	return contactController.save();

24

}

25

}

Note how Visualforce pages are first class citizens in the Apex language. In the above code, Page.step1 references a Visualforce page called step1, and if a button is bound to this action, the controller will redirect the user to the step1 page.

Finally, extensions provide the ability to augment standard or custom controllers. With extensions you can extend data access, adding logic or conditional navigation to an existing controller. An extension class is defined by providing a constructor which takes the controller type being extended as its argument. The following class definition extends the standard controller:

1	public class AccountExtension {

2

3	public Account account { get; set; }

4	public AccountExtension(ApexPages.StandardController controller) {

5	account = (Account) controller.getRecord();

6

}

7

}

Adding this controller to the page requires a simple change to the page component tag:

view source

print?

1	<apex:page standardController="Account" extensions="AccountExtension">