Contributions API

This example demonstrates how form elements can be built in a hierarchical fashion by expanding and layering the form array. There are two functions involved - the function that builds the form, and another that displays the form using drupal_get_form().

Notice that the first layer is made up of two form groups, 'access', and 'details', and that inside each of these groups, one layer down, are some individual form elements. Order of construction is important here, as the form building code will default to the constructed order of the $form array when it builds the form (this can be overridden, and will be discussed later in the custom theming section).

For form groups, the '#type' parameter is set to 'fieldset', and notice how the 'details' form group is made into a collapsed form group with the addition of a few attributes.

All groups/elements are been built into the master $form array by the builder function.

The drupal_get_form function is the "key" function in the Forms API. Note that in its basic usage, it takes just one argument, a string which is both the form ID and also the name of the function that builds the $form array. drupal_get_form can take optional additional arguments, which will be simply passed on to the $form builder function.

• Starts the entire form-building process by getting the $form from the builder function
• Translates the $form['name'] items into actual form elements
• Performs any validation and "clean-up" that needs to be done, and calls custom validation functions if declared
• Submits the form if a submit function is declared, and the form has been submitted
• Calls any custom theming functions that have been declared
• Returns an HTML string which contains the actual form.

For more detailed information, also see the developer documentation [link coming soon]

An important thing to note: notice that $form['access'] has a '#tree' => TRUE attribute. this setting retains the full tree structure for all elements under it when it is passed to $_POST['edit'] and $form_values. you must explicitly declare this anywhere you wish to retain an array's full hierarchy when it is passed.

Theming Forms

The API makes custom theming of all forms (including those found in core) possible. This custom theming becomes possible when all hard coded theming elements have been abstracted, so that they can be overridden at time of form generation. The abstraction is accomplished using one of the following two methods:

1. Including any markup directly as an element in the $form array:
   • There are '#prefix' and '#suffix' attributes, and these will place the declared markup either before or after the form element in question. for example:
     <?php
$form['access'] = array(
  '#type' => 'fieldset',
  '#title' => t('Access log settings'),
  '#prefix' => '<div class="foo">',
  '#suffix' => '</div>',
);
?>

     ...will place the div tags before and after the entire form group (meaning the form elements of the group will also be enclosed in the div). if you were to put those attributes in one of the form elements inside that form group, then they would only wrap that particular element, etc.

   • There is a '#markup' type which you can place anywhere in the form, and its value will be output directly in its specified location in the forms hierarchy when the form is rendered. example:
     
     
     <?php
$form['div_tag'] = array('#type' => 'markup', '#value' => '<div class="foo">');
?>

     This markup form element can then be accessed/altered through its name in the array, 'div_tag'

     NOTE: it's not necessary to explicitly declare the type as markup, since type will default to markup if none is declared.

2. Break out any markup into a separate theme function. This is the preferred method if the markup has any degree of complication. it is accomplished by creating a theme function with theme_ prepended to the name of the form ID that is to be themed. in cases where you want to use the same theming function for more than one form, you can include the optional callback arg in drupal_get_form--in which case the third arg of drupal_get_form will be a string containing the name of the callback function which the form building code will call, and the theming function will be theme_ prepended to the name of the callback.

   example:

   For our above form, we could create a custom theming function as follows:

   <?php
function theme_test_form($form) {
  $output = '';
  $output .= drupal_render($form['name']);
  $output .= '<div class="foo">';
  $output .= drupal_render($form['access']);
  $output .= '<div class="bar">';
  $output .= drupal_render($form['details']);
  $output .= '</div></div>';
  $output .= drupal_render($form);
  return $output;
}
?>

   A few things to note:

   1. The theme function has one argument, which is the form array that it will theme
   2. You build and return an output string just as you would do in a regular theming function
   3. Form elements are rendered using the drupal_render function
   4. If you call drupal_render and pass it an array of elements (as in a fieldset), it will render all the elements in the passed array, in the order in which they were built in the form array.
   5. While the default order of rendering for a form is the order in which it was built, you can override that in the theme function by calling drupal_render for any element in the place where you would like it to be rendered. In the above example, this was done with $form['name'].
   6. The rendering code keeps track of which elements have been rendered, and will only allow them to be rendered once. Notice that drupal_render is called for the entire form array at the very end of the theming function, but it will only render the remaining unrendered element, which in this case is the submit button. calling drupal_render($form) is a common way to end a theming function, as it will then render any submit buttons and/or hidden fields that have been declared in the form in a single call.

Validating Forms

The form API has general form validation which it performs on all submitted forms. If there is additional validation you wish to perform on a submitted form, you can create a validation function. the name of the validation function is the form ID with _validate appended to it. the function has two args: $form_id and $form_values. $form_id is the form ID of the passed form, and $form_values are the form values which you may perform validation on.

Here's an example validation function for our example code:

Submitting Forms

The preferred method of submitting forms with the API is through the use of a form submit function. This has the same naming convention and arguments as the validation function, except _submit is appended instead. Any forms which are submitted from a button of type => 'submit' will be passed to their corresponding submit function if it is available. This method is more secure than grabbing $_POST['edit'] and using a switch statement.

example:

a few things to note:

1. A submit function is called only if a submit button was present and exists in the $_POST, and validation did not fail.
2. The $form_values array will not usually have the same hierarchical structure as the constructed $form array (due to the flattening discussed previously), so be aware of what arrays have been flattened, and what arrays have retained their hierarchy by use of the tree => TRUE attribute. notice above that 'statistics_enable_access_log' belongs to a tree'd array, and the full array structure must be used to access the value.
3. If a form has a submit function, then hidden form values are not needed. Instead, any values that you need to pass to $form_values can be declared in the $form array as such:
   
   
   <?php
$form['foo'] = array('#type' => 'value', '#value' => 'bar')
?>

   This is accessed in $form_values['foo'], with a value of bar. This method is preferred because the values are not sent to the browser.

4. The return value of the _submit function will be the target of a drupal_goto; every form is redirected after a submit. If you return nothing, the form will simply be redirected to itself after a submit. It is polite to use drupal_set_message() to explain to the user that the submission was successful.

Understanding the Flow

A difficult concept with Forms API compared to the previous (Drupal 4.6) method of doing things is that the drupal_get_form() function handles both presenting and responding to the form. What this means is that the $form array you construct in your function will be built first when the form is presented, and again when the form is submitted. In the previous Drupal forms API, the check for 'submit' was done before calling any of the form_* functions, because those directly created the output.

The practical upshot to this is that many developers immediately find themselves asking the question of "where does my data get stored?". The answer is simply that it doesn't. You put your $form data together, perhaps loading your object from the database and filling in #default_values, the form builder then checks this against what was posted. What you gain from this, however, is that the FormsAPI can deal with your data securely. Faking a POST is much harder since it won't let values that weren't actually on the form come through to the $form_values in your submit function, and in your 'select' types, it will check to ensure that the value actually existed in the select and reject the form if it was not.