I've dealt recently with two widgets for node reference and had issues with both that involve stuff that aren't bugs.. doing things that aren't quite supported? I've found workarounds for both my issues, figured I'd mention them here in case there might be valid use cases for changes in cck instead of ugly-workarounds

For node reference url they were having issues with fallback autcomplete due to lack of delta; it switches between select, checkboxes, and autocomplete in the settings for the field=> widget so could not call "content handle core" for the autcomplete, thus endeding up with the value in the form [nid][nid] instead of [0][nid][nid].
The validate function in the field requires that delta thus was erroring out.
http://drupal.org/node/432978 Here's the issue.
http://drupal.org/node/432978#comment-1692968 the workaround
http://drupal.org/node/432978#comment-1696948 What could change in node reference to support the use case of note having the delta.

In another widget (something I'm doing for myself, still in major development but example viewable here http://dev.intheclosets.com/node/add/baby field papa don't lie)

I have a widget content handle core that one part of it is an autocomplete node reference

declaration

   $element[$field_key] = array(
          '#type' => 'nodereference_autocomplete',
           '#value' => array('nid'=>($node->nid?$node->title . ' [nid:'.$nid.']':'')),
                   // The following values were set by the content module and need
                   // to be passed down to the nested element.
                   '#title' => $element['#title'],
                   '#required' => $element['#required'],
                   '#description' => $element['#description'],
                   '#field_name' => $element['#field_name'],
                   '#type_name' => $element['#type_name'],
                   '#delta' => $element['#delta'],
                   '#columns' => $element['#columns'],
                   '#parents' => $element['#parents']?$element['#parents']:array(),
                   '#attributes'=> $attributes,
                   '#after_build'=>array('nodereference_node_fix'),
                   '#element_validate'=>array('nodereference_node_fix_weight'),
     );

The issue is having the pass the node has a ['#value']. It's a very obscure issue (ie took ), but having that completly blows away the '_weight' (took me forever to figure this out; there's a form_set_value if '#value' is set in _form_builder_handle_input_element). Again, I figured out an ugly workaround but perhaps _process functions should allow for ['#default_value'] .

ie

 '#default_value' => isset($element['#value']) ? $element['#value'] : '',   

could be

 '#default_value' => isset($element['#value']) ? $element['#value'] : ( $element['#default_value']? $element['#default_value']:''),   

I'm not sure how valid this is for CCK 3 since I haven't tried cck 3

Comments

hefox’s picture

Category: support » feature

Oops :/

markus_petrux’s picture

Category: feature » support
Status: Active » Fixed

CCK widgets (and generally any form element) that expands into more levels in the form cannot be altered from hook_form_alter() directly. You should install an after_build callback and scan the form recursivelly. This is executed when all items in the forms have been expanded, so you can now change almost anything you wish.

See the CCK Handbook for developers for examples on how to use hook_form_alter() + after_build callback.

Status: Fixed » Closed (fixed)

Automatically closed -- issue fixed for 2 weeks with no activity.