• Page
|
• Edit

An Introduction to the Force.com IDE

Abstract

The Force.com IDE is a powerful client application for creating, modifying and deploying Force.com applications. Based on the Eclipse platform, it provides a comfortable environment for programmers familiar with integrated development environments, allowing you to code, compile, test, package and deploy all from within the IDE itself. Much of the actual work, such as compilation, happens on the Force.com platform—the Force.com IDE performs the communication and result parsing transparently.

The IDE also features an embedded schema explorer for a live view of your database and metadata components. Using the standard synchronization features of the IDE, you can create a project that enables multiple developers to develop against a shared source code repository. This article provides an overview of the Force.com IDE and its features.

Getting Started

The Force.com IDE is available for download from developer.force.com. The installation instructions walk you through the installation of the IDE. Once installed, start up the IDE and select Window > Open Perspective > Other > Force.com to access the main interface of the Force.com IDE. You should see something similar to following screen:

The easiest way to get started is to choose File > New > Force.com Project. After entering the credentials for your Force.com organization, you will be able to select which metadata components (objects, classes, pages, etc.) you want to work with in the IDE.

The following sections explore various aspects of this interface for typical programming tasks, such as code development, testing and deploying.

Coding in the Force.com IDE

The Force.com IDE sports a number of features that facilitate code development. The following sections examine each of the features in a little more detail.

Browsing project structures

Like most integrated development environments, the Force.com IDE organizes application resources into projects. Unlike traditional software development projects where source code is compiled to create executable binaries, the resources in a Force.com project live within a Force.com organization and are copied into the local project for editing. You’ll find the following folders and files in every Force.com project:

• src/ – This folder contains all of the metadata components you have included in your project, organized by type into subfolders such as classes, objects, and pages.
• src/package.xml – This control file, known as the project manifest, determines what metadata components are retrieved from the server when synchronizing with the project’s home organization.
• salesforce.schema – Opening this file activates the Schema Explorer for the project’s home organization.
• Referenced Packages – This folder contains the contents of any managed packages that are installed in the project’s home organization. These files are read only; customizing installed managed packages from the Force.com IDE is not supported.

The Package Explorer in the IDE shows a typical Force.com project:

Coding in Apex

The Force.com IDE provides a code editor for adding, modifying and testing Apex code. You can use it to write database triggers as well as any kind of Apex class, for example, Visualforce controllers, Email handlers, or classes holding business logic.

The editor boasts a number of features:

• Syntax highlighting for Apex keywords
• Code assist for Apex system classes, user-defined classes, and schema objects
• Click-to-line integration with errors and testing views
• Unlimited undo and redo
• Tabbed views of source code and XML metadata definition

Here’s a snapshot of a simple trigger being coded in the IDE:

When Apex code is saved, it is automatically sent to the server for compilation. The Problems view displays any errors that result from that compilation:

Double-clicking on an error in the Problems view takes you right to the file and line where the issue was detected. Once the problem is fixed, save the file to send it back to the server, which updates the Problems view automatically.

Another useful tool for Apex development in the IDE is the Execute Anonymous view, which allows you to run an anonymous block of Apex on the server. Anonymous blocks help you to quickly evaluate Apex on the fly, or to write scripts that change dynamically at runtime. For example, you might write a client Web application that takes input from a user, such as a name and address, and then use an anonymous block to insert a contact with that name and address into the database. The Execute Anonymous view is a convenient way to run and test these blocks of code.

Testing

One of the most important and powerful features of the Force.com platform is its built-in support for automated testing, and the Force.com IDE boasts a robust testing harness for using this feature.

The Apex language includes the ability to define and execute unit tests, which are pieces of code that verify your application works the way you intended. Each unit test is defined as a test method, which can be part of any normal Apex class or a special Test class. The Force.com IDE provides an Apex Test Runner view where you can test your methods to see which tests are passing or failing:

You can activate the Apex Test Runner by selecting one or more Apex classes in the Package Explorer, then right-clicking and selecting Force.com > Run Tests. All Apex test execution occurs on the servers, so in order to use the Apex Test Runner view you must first save any changes.

The left pane of the Apex Test Runner summarizes the test results, identifying any test failures and showing, of the Apex classes and triggers invoked by the set of tests, which meet the minimum code coverage requirements for deployment to production, and which do not—including a list of all lines not executed. The right pane displays the output of Apex debug statements and other system log events captured during test execution. This information is useful for troubleshooting code, performance tuning, and checking resource usage. To deploy to a production organization, all Apex classes and triggers need at least 75% code coverage from tests. Ideally, you should strive for 100% coverage. This code coverage restriction is not enforced in Sandbox or Developer Edition organizations, making them the ideal places to write your code and tests. See An Introduction to Apex for more information on writing unit tests.

Working with Other Metadata Types

Besides Apex classes and triggers, a number of other types of metadata can be downloaded into Force.com projects, including Visualforce pages, schema objects, and workflow rules. These components are represented as XML documents and open in an editor that is aware of the XML tags available for each component type:

Because the metadata files are text-based, they also can be compared using text diff tools, managed in a version control system such as CVS or Subversion, and even deployed from one Salesforce organization to another.

Schema Explorer

The Schema Explorer is a tool for browsing the objects and fields in a Force.com organization. The browser presents the logged-in user’s view of the Force.com database model, including object visibility, permissions, data types, lookup values and other information that is useful in developing applications on the Force.com platform.

The Schema Explorer is depicted as a hierarchical tree view of your organization’s schema. It is read-only and does not interact with the rest of the workspace in any way.

In our sample project, double-click "salesforce.schema" to open the Schema Explorer.

You will then be presented with the Schema Explorer in its own view:

The right hand side panel of the browser is the hierarchical tree view of all the objects in the database. You can use this to drill down to an object of interest, and select fields within that object. The query pane on the left will then automatically be filled with a SOQL query that returns those objects and fields. Or you can enter your own SOQL query right into the box. Hitting the Run Me button will execute the query and show the results in the table below.

Use the schema explorer as a handy reference to your objects and their metadata. It can prove invaluable when writing Apex to look up the system names of objects and fields, test a SOQL query, or browse the live data in your organization.

Project Synchronization

Before exploring the deployment features of the Force.com IDE, it’s worth looking at how it works under the hood. In a typical working environment, the Force.com IDE is in communication with the Force.com platform servers. For example, when you hit save on an Apex class, the IDE sends the Apex class the Force.com servers. The servers compile that class and return the result (for example, parsing errors, or compilation errors) back to the IDE where they are displayed. This is the typical mode of operation - the online mode. Projects can also be in offline mode. In this case, any changes you make are simply made on your local machine. When you go online, you can synchronize those changes.

The Force.com IDE performs the communication with the servers using the Metadata API . You can think of your application as metadata to the Force.com servers. The servers take the metadata, and create a running application that you access as a service. These metadata include the code you write, the persistent objects, triggers, page layouts and more.

What set of metadata is important to you? Well, it depends. If you’re just creating Visualforce pages, for example, you may simply be interested in the Visualforce page source and Apex controller classes. If you’re just coding triggers, you may simply be interested in triggers. So the set of metadata that you’d be interested in will depend on your role and tasks.

Let’s make this more concrete. When you create a new project on the IDE, it’s going to present you with a screen that looks something like this:

The Force.com IDE is highly configurable in this respect. When you create a Force.com project in the IDE, that project is a reflection of the metadata that you select as important. The default set of metadata includes Apex classes, triggers, components and static resources. As you can see from the above figure, the IDE shows you which components in your organization meet these criteria - for example, here the IDE will grab the MileageExtension class and a number of other Apex classes and Visualforce pages.

If your organization had other metadata components, such as a page layout or workflow component, the IDE would not retrieve them because they are not selected. This is all configurable though. If you select "Select metadata components" when creating your project (see above figure), or right click on a project and select Force.com > Add/Remove Metadata Components, you will be presented with a screen that allows you to configure your IDE as to which metadata components it subscribes to:

Why is this important? Well, if your IDE is subscribed to a component (such as a page layout), then whenever you refresh your project from the server, the file in your project will be updated to reflect any changes made on the server since you last refreshed it.

The following diagram depicts this kind of IDE communication:

Here, imagine you have a Force.com IDE project that is subscribed to the Triggers, Apex Classes and Visualforce Pages metadata components in a Developer Edition organization. When you edit and save a file, that component will be synchronized automatically with your organization. If you want to send a file to the server without editing it, right-click the file (or folder) and choose Force.com > Save to Server to perform a save to your organization. You can also right-click and select Force.com > Refresh from Server on any metadata component (or folder) to grab the latest version. Finally, you can right-click and select Force.com > Synchronize with Server to see differences between your project and organization in a three-way comparison view.

Deployment

Once you have created your application components and unit tested them in your own development organization, you may want to migrate them to a different organization for such purposes as testing, staging, publication, or production use by end users. For example, you will often find yourself coding and synchronizing with a Development Environment organization. If you’re happy with those changes, you will want to deploy the changes to a sandbox for testing against a copy of your production data. The Force.com IDE facilitates this deployment, and it is highly configurable. To deploy a project, or a subset of a project, to an organization, right click on the component or folder and select Force.com > Deploy to Server. You will then be prompted for connection details to the destination organization. Once you have entered these, you can select the metadata components to upload. For example, you may select just a trigger and the test class that accompanies it. Once you’ve determined what to deploy, you can either validate the deployment—fully executing the deploy process on the server, including running tests, without actually committing the changes—or execute the deployment so your changes are saved. If the deployment fails for any reason, you will be presented with a list of each error or test failure so you know what to fix.

Version Control for Force.com Apps

As the Force.com IDE is built on the Eclipse Platform, you can also use standard Eclipse features such as version control support. A version control system allows you to track changes to a set of files over time. Using Eclipse’s version control features in tandem with the Force.com IDE allows you to store your Force.com applications in source control, compare current and historical versions of a component, roll back changes, and work collaboratively by sharing a single application definition across a development team. Eclipse can connect to the popular, open source Subversion system using a plug-in called Subclipse. Once installed, you will be able to retrieve source code from a Subversion source code repository, including Code Share projects created by the Force.com developer community.

Summary

The Force.com IDE is a powerful tool for creating, modifying and deploying Force.com applications. The Schema Explorer provides a live view of your database and metadata components, automatic synchronization keeps your code and organization in step, the testing environment lets you quickly and easily run Apex tests against your code, and the deployment features let you seamlessly deliver changes from one environment to another. The addition of source code syntax highlighting and code assist, as well as version control integration through Eclipse, make the tool an important part of developing on the Force.com platform.

References

• Developer.force.com provides access to free developer edition accounts, which you can use to start developing applications immediately. It also provides links to documentation, forums, and more.
• The Force.com IDE page on developer.force.com provides a home for all things related to the IDE, including installation instructions and an FAQ.
• An Introduction to Apex provides a technical introduction to the Apex language, providing a lot more detail on all topics covered in this document.
• An Introduction to the Force.com Database provides more details on the database, query language and persistence mechanisms described in this article.

About the Author

Jon Plax is the product manager for platform developer tools, including the Force.com IDE, at salesforce.com.