Taming CCK configurations with CoCKTaiL

In this session, I will describe CoCKTaiL, the CCK Type Language project, and demonstrate how tools
based on CoCKTaiL can save time while reducing errors and improving code quality and maintainability.

Session outline

• Introduction; examples of issues with CCK
• Demonstration of CoCKTaiL tools
• Motivations and design considerations
• Discussion of future directions; your input!

Everyone Loves CCK (but we grumble, too)

Drupal’s Content Construction Kit (CCK) is a powerful feature, much loved by Drupal developers, who use it to rapidly define data types and relations for applications. The ability to interactively create new types and supporting UI’s is a great time-saver in the early
stages of many Drupal development projects.

For larger projects, however, the nature of the design and implementation process for CCK types leads to difficulties in evolving and maintaining projects which include CCK components, and these difficulties contribute to the lifecycle cost of large Drupal
applications.

Examples of issues with existing CCK support:

• Hey, who changed the CCK definitions? If you’ve worked on a team building a site involving a lot of CCK types, you may have had the joy of discovering that a type definition has mysteriously changed. By the time you discover who made the change and why, and what the impact is on your code, half a day has gone by…

• We need the twelve CCK defs from site X, but with a new userref in some of the types and different labels for some of the titles… “Sure, no problem. We’ll export the types one by one, then import them and make the changes in place.” Meanwhile, time passes…

• I’ve been given a gorgeous UML diagram specifying all the types, fields and relationships spec’d by the IA… now what? Wouldn’t it be nice to be able to translate that into a high-level specification that will generate the CCK for you?

Additionally, there’s little support for re-usability - typically, many projects involve using the same kind of types over and over again. Building these by hand is boring and repetitive; the current CCK export and import facility does not easily allow variations or changes.

Introducing CoCKTaiL

A possible solution to many of these issues would be a suitable ‘high-level’ representation of CCK types, for description, modeling, exchange, and design-build automation, written in a formal type language.

Here is an example a type definition specified via CoCKTaiL. Compare the ease of typing this to the time involved in generating this via the CCK click-and-wait user interface.


// CoCKTaiL Type definition for Client info
type 'Client info' {
description 'Basic information about a client';
titlelabel 'Name';
bodylabel 'Description';
status false;
comment 2;
group 'Contact info' {
style fieldset;
description 'Contact info for Client';
display_label inline;
field text 'Street address 1' {}
field text 'Street address 2' {}
field phone 'Home phone' {}
field phone 'Mobile phone' {}
}
field textarea 'Notes' {
rows 3;
}
}