custom cck field development

Reference material: cck hook docs found here: http://drupal.org/node/342987,
Karen Stevenson (http://www.lullabot.com/articles/creating-custom-cck-fields)
Jennifer Hodgdon (http://poplarware.com/articles/cck_field_module)
link and cck/optionwidgets modules

GOTCHAS:

Gotcha #1
// implementation of hook_field_info

function classnote_degree_field_info() {
return array(
'degree' => array(
'label' => t('Degree'),
'description' => t('Stores a degree with the year it was earned.'),
)
);
}

// implementation of hook_widget_info

function classnote_degree_widget_info() {

return array(
'degree' => array(
'label' => 'Degree/Year selector',
'field types' => array('degree'),
'multiple values' => CONTENT_HANDLE_CORE,
'callbacks' => array(
'default value' => CONTENT_CALLBACK_DEFAULT,
)
)
);
}

if field_type in hook_widget_info doesn't match an array key from hook_field_info, your field won't show up in the cck | manage fields UI.

GOTCHA #2:

function classnote_degree_field_settings($op, $field) {
switch ($op) {
case 'form':
$form['initial_year'] = array(
'#type' => 'textfield',
'#title' => t('What year did you begin awarding degrees?'),
'#size' => 10,
'#default_value' => $field['initial_year'] ? $field['initial_year'] : date('Y')-50,
'#required' => TRUE
);

...

#default_value needs a ternary operator or variable that's set before the form definition, or else you'll lose your previous settings when the edit form loads.

---

My preferred order of operations is to get the ui piece of it working first...

Bits related to the node edit form

hook_field_info() is needed to get the datatype available to the manage fields interface.

hook_field_settings() to define database tables
note: if this isn't defined, nowhere to save the data.

hook_widget to define the form elements in node_edit form
Note:

Then think about making the options configurable...

hook_field_settings()::op=database columns handles database storage

hook_field()::op=validate does the form validation.

CCK does no checking to see if the various parts are consistently implemented - doesn't look at db fields and see if they match fields in code, for example. That means you can make a false start, don't clean it up cause you don't understand the database tables are orphaned, and then change your code and you can't figure out why it doesn't save...no fields to save to.

CCK makes new tables PER FIELD INSTANCE - add a field, make a table. So if you make changes to your cck field module, delete your cck fields and start over in your content type.

Posted via email from dsayswhat's posterous