Renaming Field API groups

We encourage users to post events happening in the community to the community events group on https://www.drupal.org.
bjaspan's picture

We currently have three Field API groups: CRUD, Type, and Attach. As recently as Monday, chx was confused about what these names mean; he thought "Attach" was for attaching a field to a bundle. If he can be confused, then the names are just confusing. I propose that we change them as follows:

  • Field Definition API (formerly CRUD). Functions used by modules to create content types and/or fields for themselves or other modules to use. Functions use the "field_" prefix, e.g. field_create_field(). We could also use field_defn_create_field() but I think that is unnatural. field_definition_*() is just too long and unwieldy to contemplate. NOTE: This is my least favorite name, please suggest alternatives.
  • Field Type API. Hooks that let modules define field types (text, image, nodereference...) and their 'plugins' (form widgets, display formatters). I propose changing hook_field_info() to be hook_field_type_info(), to be parallel to hook_field_widget_info() (which itself was renamed from hook_widget_info() yesterday) and hook_field_formatter_info().
  • Field Data API (formerly Attach). Functions used by modules that implement object types that want to support having fields attached, like Node and User. These are the only Field API functions that actually interact with user-provided content. Functions use the "field_data_" prefix, e.g. field_data_load(), field_data_presave().

I would like to make this change before releasing the final report, and I want to release the final report yesterday. So, please comment on this ASAP. :-)

Comments

"Attaching" can indeed be misleading

floretan's picture

I've been confused by the field_attach_* prefix as well, since we commonly speak of attaching fields to a content type which is a different thing. The field_data_* prefix gives a much clearer idea of what the functions actually do.

I'm mostly rephrasing what Barry wrote, but I would say that we want the following:

  • field_* prefix for functions that create/read/update/delete fields.
  • field_{type,widget,formatter}_* prefix for functions that define field types, widgets and formatters.
  • field_data_* prefix for functions called by the various fieldable entities to load or save field values.

Field definition API :

yched's picture
  • Field definition API : fine by me, no better suggestions right now. +1 on keeping function names as field_create_field(). Other suggestions don't fit. As per the 'doesn't distinguish from the general field_* namespace' issue, we could argue that field_create_*, field_update_*, field_delete_* etc are their own namespaces :->.

  • Field Type API : why not, except that it forces us to add 'and their plugins (widgets, formatters)'. No better suggestions right now.

    hoo_field_info() -> hook_field_type_info() : I think I agree.
    But arguably, we find the same distinction between 'widget type / widget', 'formatter type / formatter'.
    hook_widget_info() describes widget types. The 'widget' is what is used in an actual form, and is an instance (hem) of a widget type. CCK just currently merges the two under the term 'widget' (IMO thes distinctions are painful because the natural formulation of field types, widget types etc is OO. We don't want to go there right now :-), but it nonetheless is.)

    So I'd vote for hook_field_widget_type_info(), hook_field_formatter_type_info() too.
    Then, why not drop the _info ? And switch to plural for accuracy (your module can expose several field types, several widget types etc...)
    -> hook_field_types(), hook_widget_types(), hook_formatter_types() ?

  • I really did like 'attach' ;-). It's the api that you use to make your objects have fields attached to them. Sounded like the perfect match to me. Ah well.
    What bugs me with field_data_* is that this API is a little more than just about 'data' operations.
    It also includes field_attach_[create|rename|delete]_bundle(), which do not map very well to the field_data_* namespace.
    It also includes hook_fieldable_info(), field_build_modes() (the exact fate of the latter will need be discussed in a future '$node->build_mode cleanup and rehaul' core patch)

    Maybe we could use field_fieldable_*() ? (or even just fieldable_*() ?). Then we could have hook_fieldable_info() back in the scope of this API.

Fields in Core

Group organizers

Group notifications

This group offers an RSS feed. Or subscribe to these personalized, sitewide feeds: