By davidm on

Overview:

"The Content Construction Kit allows you create and customize fields using a web browser. " (http://drupal.org/project/cck) Fields can be aggregated into custom content types. CCK was based on the Drupal Flexinode module, and general CMS design (http://drupal.org/node/17302 - "I would recommend looking into Daisy CMS approach in this matter"). CCK provides Web based content definition through forms, as well as database storage, and validation rules. Presentation is generally handled through the Views or contemplate modules, but it is also possible to manipulate CCK data using PHP in a module or template.

CCK has been extended in recent versions to include automated import-export functionality for data types and data, and custom field types. Custom field types are useful in that they can be used between aggregated content definitions (content), although there's no model for actual data access of specific content types. So, a generic, re-usable field called "Country" can be defined with storage and validation rules, but a module cannot access particular content data (MyModule's Country) without custom code.

Problem:

I am working with a client who would like to use CCK for the perceived benefits of re-usable fields, vs using a completely custom module, for their new Drupal 6 instance. The module being developed is similar to the Signup module in workflow. My perception is there would be few advantages to using CCK, and many drawbacks. Specifically:

  • CCK is primarily designed for point and click creation of content, with point and click creation of views using the Views module. Is CCK even intended to be used from a custom module, or is the only intended use through Views and template formatting?
  • CCK is in constant flux ("An initial alpha release of a D6 version is now available. It is ready for testing but not production. It is designed to work with the current development version of Views 2. Views 2 is still in flux and compatibility issues could arise if there are significant changes."). This has generally been the case with the CCK/Views modules since their inception, making them moving targets with issues for long term reuse; modules would have to be constantly upgraded. While this is always the case with software like Drupal, the combination of flux in core Drupal, CCK and Views may mean more drawbacks than advantages when using this combination.
  • Because CCK is often in flux, required updates, to accommodate other functionality or security fixes, may break functionality in the developed module.
  • CCK is not a core module, and might be deprecated. It might be better to rely solely on core Drupal facilities.
  • A considerable number of hacks and third party modules will be required for full control over CCK content.
  • Creating a custom module rather than building on the abstraction of CCK can make content reuse more practical.
  • The documentation for using CCK and associated modules, patches and hacks (no other description) is often out of date or incorrect. There is no consolidated, straightforward overview. The documentation for CCK itself is intended for Drupal 5.x.

Can anyone comment on these issues? If CCK is indeed suitable, a clear Drupal 6 module that accesses a created CCK content item (not defines field definition) would be particularly appreciated.

Thanks!

David

⋅ Categories: Drupal 6.x

Comments

dwees’s picture

dwees commented

The way I see it, the points you bring up are all valid ones. However I have been using CCK for a couple of years now without any difficulty during its transition from a 4.7.x - maybe this module is useful to 5.x - everyone is using this module. One thing which has not changed in CCK in its 5.x version is the way the cck fields are accessed. I think this has changed in Drupal 6, but my guess is you wouldn't have to worry about data definition types changing again until possibly Drupal 7.

Another possible reason not to use CCK is because of the additional overhead. Whenever you view a node, you have to first load the cck definition for that node type, THEN load the additional cck data. If you use a custom field in your module, you skip the first of these two steps. If you have a very high traffic site, this could be an issue.

As for the depreciation of CCK, I doubt this will be an issue. If the module is depreciated, it will be because its functionality has been included in Drupal core.

Documentation for any module remains a task to be completed. This is because many of the module maintainers are doing so without being paid for their work, and traditionally coders aren't very good at documenting what they've done. I'm sure some computer science school emphasizes the need for documentation and builds this requirement into programs of study, but certainly not most schools.

The security fixes for CCk as I understand it, have generally presentational rather than structural. This means that when a security fix does come out, it's pretty safe to assume that you won't have to modify your code, except possible in the theming layer.

Maybe someone else has some points to bring up?

Dave

My site: http://www.unitorganizer.com/myblog

dgtlmoon’s picture

dgtlmoon commented

Hey there.. Well i came across your entry because I was trying to find out if I could use CCK field types in my own module, for example, I want to provide an imagefield in my own hook_form, but imagefield is for CCK.

Is that what you mean?

davidshaw’s picture

davidshaw commented

I too stumbled here on a google search so thought i'd answer this for the next person who ends up here:

First enable an imagefield on yourmodule content type and give it a name field_yourimagefield

//Then include the necessary code
module_load_include('inc', 'content', 'includes/content.node_form');

//Now add the field to your $form 
  $field = content_fields('field_yourimagefield', 'yourmodule');
  $form['#field_info']['field_yourimagefield'] = $field;
  $form += (array) content_field_form($form, $form_state, $field);