Abstract
In this post, we describe some of the issues facing large or complex software projects using Drupal's CCK content type extension facilities. We then propose a remedy in the form of CoCKTaiL, a high-level language for CCK types and associated UI elements and relations. Tools and potential applications will be described in future work.
Introduction
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. Using a UI, developers can easily create new content types by specifying fields, UI widgets, relations, and more.
The ability to interactively create new types and supporting UI's is a great timesaver 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.
Challenges include:
- succinctly and precisely specifying CCK types
- importing and exporting CCK types and data to and from Drupal instances
- versioning changes to CCK configuration for Drupal instances
- migrating data between different versions of Drupal applications, and/or into or out of Drupal sites
- understanding and manipulating the data model for complex CCK based applications
- validating CCK implementations against external requirements
- rapidly, accurately, and repeatably creating and modifying CCK based type structures
- automatically generating CCK types and supporting code from high-level descriptions
- and many others...
Examples of issues with existing CCK
Hey, who changed the CCK definition?
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 CCK defs from site X, but with a new userref in all types and different titles for some of the types!
"Sure, no problem. We'll export the fields one by one, then import them and make the changes in place." Meanwhile, time passes...
I've been given a gorgeous ER diagram specifying all the types we need, their fields and relationships... 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?
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.
I have been working on such a language, which I have called CoCKTaiL (for CCK Type Language); one of my goals has been to ensure that CoCKTaiL:
- allows full and precise definitions of CCK types, UI elements, etc.
- is compact
- is implementation language independent
- is a textual representation (works with version control and text editing tools)
- has a formally specified (context-free) syntax for machine generation and parsing
- "null" options correspond to sensible defaults
- is human readable and writable
- is familiar? (what are analogs?)
- is extensible, to handle extensions to CCK
- add productions to grammar, snippets and rules to code generator
- each CCK type module would include extensions (hooks?)
- is well-supported by tools:
- a parser
- validator
- CoCKTaiL blender (UML -> CoCKTaiL)
- CCK type generator (CoCKTaiL -> CCK code)
- CCK code de-compiler (CCK -> CoCKTaiL)
- is a suitable target for automatic translation to/from UML: (E.g. UML -> CoCKTaiL -> CCK code, and roundtrip?)
Examples
Here is an example what of a type definition specified via CoCKTaiL might look like. (Compare the ease of typing this to the time involved in generating this via the CCK user interface)
// CoCKTaiL Type definition for Client info
type 'Client info' {
description 'Basic information about a client';
title_label 'Name';
body_label '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' {}
}
Next steps
In my next post I will describe a formal (LALR(1)) grammar which describes CoCKTaiL, and some tools which I am using to develop a validator, code generator, and some other tools.