Last week Dr. Sameer Verma invited me to give a presentation on using Drupal's CCK & Views modules at an all day open workshop he was giving to promote FOSS use in preparation for Software Freedom Day 2009 here in Jamaica. It is very nice to see Drupal being recognised as a substantial member of the FOSS comunity.
One of the more interesting DrupalCon DC sessions from my perspective was one describing the in-progress core Fields module. It is heavily based on CCK and will replace CCK in Drupal 7. The development is ongoing and has benefited from a number of recent code sprints.
I'm excited about this module for a number of reasons. First and foremost, it will allow fields to be added to any object- not just nodes. This includes Users, Nodes, Comments, data pulled from outside sources - whatever. Needless to say this is going to be very useful, potentially replacing modules like Profile with core functionality.
This is done through some carefully thought-out APIs that will once again change how custom field types are created, though hopefully for the better. According to the presentation (found below) it's a return to the data level/GUI level pattern found in D5 but departed from in D6. Probably the very best part, however, is that the API documentation will be included in core and will thus be accessible.
Project Page: http://drupal.org/project/node_form_rearrange
Recently I've been working on a project that requires the taxonomy selection to be better integrated with rest of the input fields in a node creation/edit form. Normally, for node types with more than one associated vocabulary, a fieldset called 'categories' or 'vocabularies' is drawn up containing each of the vocabulary's selection form element:
The Field Actions module is a very nice little module that includes a number of actions that work with CCK fields. For example, it will send an email to a user selected in a user reference field.
CCK is an excellent way of customizing node types without so much as a line of custom PHP. However, if you wish the node to be part of some sort of dynamic process where nodes interact or are part of a process, you'll probably need to delve into widgets and fields a little bit deeper.
In this case, we wanted to link a node describing a petition with node describing a petitioner (name, address, email, etc.)- and we wanted to take advantage of CCK. We have a parent-child relationship, where at least one of the nodes must have a field pointing to it's counterpart. Fortunately, the nodereference field already exists, so all we need to do is supply it with data. We're going to do just that by supplying it with the last argument of the referring URL.
