It's been a crazy and exciting week. We grappled with a lot of issues, went around in plenty of circles, and took some heat from the community. We did not accomplish nearly everything we wanted to but did achieve several important goals. The big one is that it is now pretty simple to "field-enable" any kind of object with minimal effort. We have field-enabled nodes and users.
Here's an example of using the Field API to create a new field and attach it to a node type and all users (because users do not have "content types"). This code causes the new field to be loaded and saved with the underlying object (via {node,user}_{load,save}()) and appear on the edit form and view page:
<?php
function demofield_install() {
// Create a text field.
$field_name = 'demofield';
$field = array('field_name' => $field_name, 'type' => 'text');
field_create_field($field);
// Create a field instance structure.
$instance = array(
'field_name' => $field_name,
'label' => 'Demofield Demo',
'description' => 'This is a demonstration text field.');
$instance['widget'] = array(
'type' => 'text_textfield');
$instance['display'] = array(
'formatter' => array(
'type' => 'text_default'));
// Attach the field to all users (because user.module does not
// define multiple "content types").
$instance['bundle'] = 'user';
field_create_instance($instance);
// Attach the field to "articles" (a name defined by node.module).
$instance['bundle'] = 'article';
field_create_instance($instance);
}
?>There is still plenty of code to write but the basic system is in place and functioning. Of course, we have a lot of writing-up to do. More to come.
Comments
field_name vs name
Small detail about the demo code: it is not entirely clear why we prefix some 'member fields' with "field_" (eg. field_name) while we don't do so for (all) others. It would be odd to write $field->field_name when you could just write $field->name.
Agree.
We discussed that, and I thought we decided to change $field['field_name'] to $field['name']. It will be a big search/replace and we just did not get to it. That is the sort of thing that is a LOT easier to do once the new system is working and has a bunch of tests to confirm you do the rename properly. We are in this state now, but were not earlier in the week.
Also : we could start
Also : we could start encouraging good practice early, and recommend a [module]_[name] pattern for fieldnames :
$field_name = 'demofield_demo';
don't want to create more work
so seriously feel free to tell me to wait..
but having a DB diagram of exactly how this would look would probably help us to visualize all of our concerns. chx's update was awesome and I think people get it but it also created a lot of concern.
-Jacob Redding
-Jacob Redding
Why programatically?
I think fields should be attached to node types through some hook, not programatically on hook_install().
This way modules can use all the potential of fields, and can always rely on those fields being available, kind of 'locked' fields.
This was discussed before
This was discussed before the sprint and there is no reason it can't happen. However, just as with Schema API, a declarative hook as you are describing has to be backed by a programmatic API to implement the structure declared by the hook. Thus, we implemented the API first.
I've added "hook-defined fields" as a user story to the planning spreadsheet.