,

Metadata & the Metadata API

Throughout this book, you have been reading references to Force.com metadata. As you no doubt understand by now, metadata is the driving force behind all your Force.com applications. In your work with everything from objects and fields to reports and workflow, you have been simply defining metadata, which the Force Platform uses at runtime to determine the operation of your application and its components.

The Force.com Metadata API is used to access metadata in your Force.com organization. The Metadata API is comprised of a transport, a web service API that allows reading setup information out of a Force.com organization, and a payload—the organization setup information itself. The API provides two modes that control how the configuration information is conveyed—either as text files, or as programmatic objects in web service calls.

The IDE uses the text file representation of organization metadata, so the remainder of this discussion will focus on text mode operation of the Metadata API.

Files and Types

The Metadata API provides access to the same metadata that you have been defining using the Setup menu. When you request metadata for a Force.com component from the IDE, the IDE sends that request through the Metadata API to the Force.com server. The server, in response, creates an XML file from the stored metadata on the fly.

Each component in a Force.com application returns its own file, such as a file for a custom object, an application, a tab, and so on. Some components, such as custom fields, are returned as part of the XML for their parent component. If you have a number of custom fields on a standard object, there will be one file for the standard object that includes the custom fields you’ve defined.

The files are organized into a directory structure that makes navigation to specific files easier. For instance, the files corresponding to your schema, the custom objects and custom fields, are in a directory called ‘objects’, while the files containing profile information are stored in a directory called ‘profiles’.

The Metadata API uses ZIP files to pass files between the Force.com IDE on your client machine and the Force.com servers, although that transport is transparent to your use of the Force.com IDE.

The contents of some of the files look like source code, such as Apex and Visualforce components, which you will learn about in the four chapters following this one. Others represent components that were defined declaratively through the Setup menu. These files are formatted as XML text files.

The XML files themselves contain pretty much what you’d expect, with values for the attributes you declare in the Setup menu. For example, in the case of a custom object, the text file contains the name, label, plural label, description, and help text. It also contains information about all the fields in the object, such as the name of the field, the data type for the field, and any field level help text.

Whether you create the custom object using the Force.com IDE or through the Setup menu, you get the same custom object in your organization. The final repository of the information created by wither of these methods is the metadata, regardless of how those values are created. You can think of the text files together as the source code for the applications in your Force.com organization.

Metadata Interaction

When working with the Force.com IDE and metadata, you should understand an important distinction between working with a platform like Force.com and a more traditional platform. This distinction underlies important differences between development-as-a-service and traditional development.

As stated above, all the information available to you in the Force.com IDE is metadata; however, the metadata in the IDE is copied from the metadata for your Force.com organization. When you create components, make changes in components, or delete components in the IDE, you are making these changes in your local copies of the metadata files.

The changes you make must be saved back to the Force.com server. By default, a save action in the Force.com IDE will flush your changes back to the server, which may require additional interaction to confirm that these changes should permanently alter the Force.com metadata.

Similarly, you can refresh your local copy of the metadata from the Force.com server. You can perform either of these actions, as well as additional actions, such as creating a new component, by right-clicking on the component, component folder, or top level src folder.

The figure below shows the context menu that appears when you right click on the objects category in the Package Explorer pane. The main menu contains a submenu labeled Force.com, which gives you the ability to save and refresh from the server. You can also deploy the metadata to another server, which is covered in Chapter 15: Deployment.