function date_field_widget_form in Date 7.2
Same name and namespace in other branches
- 7.3 date_elements.inc \date_field_widget_form()
- 7 date_elements.inc \date_field_widget_form()
Private implementation of hook_widget().
The widget builds out a complex date element in the following way:
- A field is pulled out of the database which is comprised of one or more collections of start/end dates.
- The dates in this field are all converted from the UTC values stored in the database back to the local time. This is done in #process to avoid making this change to dates that are not being processed, like those hidden with #access.
- If values are empty, the field settings rules are used to determine if the default_values should be empty, now, the same, or use strtotime.
- Each start/end combination is created using the date_combo element type defined by the date module. If the timezone is date-specific, a timezone selector is added to the first combo element.
- The date combo element creates two individual date elements, one each for the start and end field, using the appropriate individual Date API date elements, like selects, textfields, or popups.
- In the individual element validation, the data supplied by the user is used to update the individual date values.
- In the combo date validation, the timezone is updated, if necessary, then the user input date values are used with that timezone to create date objects, which are used update combo date timezone and offset values.
- In the field's submission processing, the new date values, which are in the local timezone, are converted back to their UTC values and stored.
File
- ./
date_elements.inc, line 45 - Date forms and form themes and validation.
Code
function date_field_widget_form(&$form, &$form_state, $field, $instance, $langcode, $items, $delta, $base) {
$element = $base;
$field_name = $field['field_name'];
$entity_type = $instance['entity_type'];
// If this is a new entity, populate the field with the right default values.
// This happens early so even fields later hidden with #access get those
// values. We should only add default values to new entities, to avoid
// over-writing a value that has already been set. This means we can't just
// check to see if $items is empty, because it might have been set that way
// on purpose. In date_field_widget_properties_alter() this is flagged if
// this is a new entity. Check !isset($items[$delta]['value']) because entity
// translation may create a new translation entity for an existing entity and
// we don't want to clobber values that were already set in that case.
// @see date_field_widget_properties_alter()
// @see http://drupal.org/node/1478848.
$is_default = FALSE;
if (!isset($items[$delta]['value'])) {
if (!empty($instance['widget']['is_new'])) {
// New entity; use default values defined on instance.
$items = date_default_value($field, $instance, $langcode);
$is_default = TRUE;
}
else {
// Date is empty; create array structure for value keys.
$keys = date_process_values($field);
$items[$delta] = array_fill_keys($keys, '');
}
}
// @todo Repeating dates should probably be made into their own field type
// and completely separated out. That will have to wait for a new branch
// since it may break other things, including other modules that have an
// expectation of what the date field types are. Since repeating dates cannot
// use the default Add more button, we have to handle our own behaviors here.
// Return only the first multiple value for repeating dates, then clean up
// the 'Add more' bits in #after_build. The repeating values will be
// re-generated when the repeat widget form is validated. At this point we
// can't tell if this form element is going to be hidden by #access, and
// we're going to lose all but the first value by doing this, so store the
// original values in case we need to replace them later.
if (!empty($field['settings']['repeat']) && module_exists('date_repeat_field')) {
if ($delta == 0) {
$form['#after_build'][] = 'date_repeat_after_build';
$form_state['storage']['repeat_fields'][$field_name] = array_merge($form['#parents'], array(
$field_name,
));
$form_state['storage']['date_items'][$field_name][$langcode] = $items;
}
else {
return;
}
}
module_load_include('inc', 'date_api', 'date_api_elements');
$timezone = date_get_timezone($field['settings']['tz_handling'], isset($items[$delta]['timezone']) ? $items[$delta]['timezone'] : date_default_timezone());
// @todo See if there's a way to keep the timezone element from ever being
// nested as array('timezone' => 'timezone' => value)). After struggling
// with this a while, I can find no way to get it displayed in the form
// correctly and get it to use the timezone element without ending up
// with nesting.
if (is_array($timezone)) {
$timezone = $timezone['timezone'];
}
$element += array(
'#type' => 'date_combo',
'#theme_wrappers' => array(
'date_combo',
),
'#weight' => $delta,
'#default_value' => isset($items[$delta]) ? $items[$delta] : array(),
'#date_timezone' => $timezone,
'#element_validate' => array(
'date_combo_validate',
),
'#date_is_default' => $is_default,
// Store the original values, for use with disabled and hidden fields.
'#date_items' => isset($items[$delta]) ? $items[$delta] : array(),
);
$element['#title'] = $instance['label'];
if ($field['settings']['tz_handling'] == 'date') {
$element['timezone'] = array(
'#type' => 'date_timezone',
'#theme_wrappers' => array(
'date_timezone',
),
'#delta' => $delta,
'#default_value' => $timezone,
'#weight' => $instance['widget']['weight'] + 1,
'#attributes' => array(
'class' => array(
'date-no-float',
),
),
'#date_label_position' => $instance['widget']['settings']['label_position'],
);
}
// Make changes if instance is set to be rendered as a regular field.
if (!empty($instance['widget']['settings']['no_fieldset'])) {
$element['#title'] = check_plain($instance['label']);
$element['#theme_wrappers'] = $field['cardinality'] == 1 ? array(
'date_form_element',
) : array();
}
return $element;
}