Custom nested element and its child sub-elements callbacks I'm trying to create a custom element that consist of a few other elements, namely some select box and one timeperiod element.

I've set up custom #process, #value_callback, and #element_validate and everything works well with one exception. The #element_validate` of timeperiod element is run after my own elemen's callback is which means I can't effectively use the results of that field for either validation or creation some structured output.

As far as I know it's a normal drupal7 behaviour, callbacks on forms are supposed to be run top->down. That said, however, I still need some after-submit callback on higher-level element that can access already final results of all of its children elements.



I'd also love to know why has top-down approach been chosen. Because no matter how much I think about it it's just completely non-sensical.



Specific example:

function TST_element_info() {
  return array(
    'station_channel' =&gt; array(
      '#input' =&gt; TRUE,
      '#tree' =&gt; TRUE,
      '#process' =&gt; array('TST_element_process'),
      '#value_callback' =&gt; 'TST_value_callback',
      '#element_validate' =&gt; array('TST_element_validate'),
    ),
  );
}

function TST_element_process($element, &amp;$form_state, $form) {
  global $user;
  $opts = array(/* magic */);
  $element['Sel'] = array(
    '#type' =&gt; 'select',
    '#options' =&gt; $opts,
    '#empty_option' =&gt; t('Tsss'),
    '#empty_value' =&gt; 'default',
  );

  ...

  $element['Per'] = array(
    '#type' =&gt; 'timeperiod_select',
    '#title' =&gt; t('Tsss:'),
    '#required' =&gt; true,
     '#units' =&gt; array(
       '86400' =&gt; array('max' =&gt; 365, 'step size' =&gt; 1),
       '3600' =&gt; array('max' =&gt; 23, 'step size' =&gt; 1),
       '60' =&gt; array('max' =&gt; 55, 'step size' =&gt; 5),
     ),
  );
  return $element;
}


function station_channel_value_callback($element, $input = FALSE, &amp;$form_state) {

  if (empty($input) || $input == 'default') {

    if(isset($element['#default_value'])) {

     /*magic*/

    } else {

      return false;

    }

  } else {

    $Sel =  $input['Sel'];
    $Per = $input['Per'];

  }

  return array(
    //I'd need need to return something like (or I could do it in validate):
    //But can't do it here because $input['Per'] contains raw input from its three textfields instead of computed timestamp (and even if I altered the module to do the computation in its #value_callback it would still not help because their callback is run after mine).

    'path' =&gt; "weirdStuff/$Sel/period/$Per/json"

     //Therefore I have to return:
    'Per' =&gt; $Per,
    'Sel' =&gt; $Sel,

  );
}

function TST_element_validate(&amp;$element, &amp;$form_state) {

  // Magic validation

  $Sel = $element['#value']['Sel'];
  $Per = $element['#value']['Per'];

  $validated_input_array = array(
     //Again, I'd need to do this but can't because timeperiod's element_validate is run after mine which means their $element['#value']['Per'] still contains raw data.
     'path' =&gt; "weirdStuff/$Sel/period/$Per/json"
  );
  form_set_value($element, $validated_input_array, $form_state);

}

//It's perfectly ok in form_submit, the form_state['#values'] contains computed (timestamp) data for the period field. But that is kinda too late for my own element.




PS: Consider this example but with one of the sub-elements that are used for connection string connection being a bit more complex one that computes its true value in #element_validate.
The whole workflow of form API is shown here  (source: https://www.drupal.org/node/165104). 

You can notice that #process is top-bottom whereas #after_build is bottom-top, and #element_validate is a whole another step and bottom-top. You can also see that #value_callback is called quite early (even before #process).

Thus, and by experience, your #value_callback should not be more than 15 lines long, and in the case of a nested element, always take form_type_checkboxes_value or form_type_radios_value as examples: they only care about edge cases and rarely modify values.

This said, another input to take into consideration is the timeperiod module, because your way of handling will depend entirely of this module. (source: http://cgit.drupalcode.org/timeperiod/tree/timeperiod.module)

/**
 * Implements hook_element_info().
 */
function timeperiod_element_info() {
  // A duration form element which represents the duration in seconds.
  $types['timeperiod_select'] = array(
    '#input' =&gt; TRUE,
    '#tree' =&gt; TRUE,
    '#default_value' =&gt; 0,
    '#value_callback' =&gt; 'timeperiod_element_value',
    '#process' =&gt; array('timeperiod_element_process', 'ajax_process_form'),
    '#after_build' =&gt; array('timeperiod_element_after_build'),
    '#pre_render' =&gt; array('form_pre_render_conditional_form_element'),
    // Controls the available units. Array keys are the units, see
    // timeperiod_element_units(). The values control the number of available
    // values per unit, taking steps in the configured size starting from 0.
    '#units' =&gt; array(
      '3600' =&gt; array('max' =&gt; 23, 'step size' =&gt; 1),
      '60' =&gt; array('max' =&gt; 55, 'step size' =&gt; 5),
    ),
  );
  return $types;
}



timeperiod_element_value() does literally nothing (see its comment)
timeperiod_element_process() breaks down into units and sets up sub-elements 
timeperiod_element_after_build() actually sets the
value


So based on these informations, you also need to implement #after_build, which is bottom-up, so it will run after timeperiod, and set the value using form_set_value()

Remember that validation is only for validation, and will always have processed values as input.