Roadmap for making Biblio use CCK nodes

We encourage users to post events happening in the community to the community events group on https://www.drupal.org.
You are viewing a wiki page. You are welcome to join the group and then edit it. Be bold!
Posted by kvantomme on February 24, 2009 at 11:11pm
Last updated by mlncn on Tue, 2009-03-17 14:45

Introduction

Currently Biblio is still using custom node types. As a result it is necessary to build bridge modules to enable integration of functionality that by default already is available to CCK content types. Also since Biblio has developed it's own functionality ecosystem there are a couple of functionalities that currently only exist for Biblio nodes.

CCK is the general trend which more and more modules have been following in the past months/year. It handles a lot of the backend stuff for you when it comes to storing, displaying and exporting your data. (this does not apply to biblio only, but all the modules in general). The trend has materialized by the fields API being integrated into core for Drupal 7. Another benefit is that porting the modules to CCK in Drupal 6 means less hassle to port the modules to Drupal 7 as this will be a common task - you can almost be sure that there will be an automatic porting process.

Potential impact

Many modules enhance the existing CCK implementation some examples are:

Duplications/extra modules that are currently necessary because of Biblio not being CCK:

  • oai2forcck a module provides an implementation the Open Archives Initiative Protocol for Metadata Harvesting (OAI-PMH) for Drupal with support for CCK content types and their fields. This module is a sister for oai2
  • biblio facets provides integration with faceted search
  • MARC is the standard format for bilbliographic records for libraries ([RJ]:Biblio can now read MARC files directly)
  • Flexible date field as requested in the following issue

There are some efforts that go in this direction:
http://drupal.org/project/scholarly

This integration question has been coming up frequently (some are duplicates):
http://drupal.org/node/116817
http://drupal.org/node/86086
http://drupal.org/node/220063
http://drupal.org/node/220005
http://drupal.org/node/234891
http://drupal.org/node/358865
http://drupal.org/node/320429

If in stead of building bridge modules we concert our efforts we should be able to reengeneer Biblio so that it works with CCK nodes instead.

Documentation

Here comes

  • a diagram of the current database tables and inter-relations
  • link to CCK Doxygen documentation

Practical

  • Evaluate the inherit project as a dependency for CCK Biblio

    One of the main road blocks is the lack of field inheritance functionality in CCK. The inherit project however aims to provide this functionality (e.g. instead of defining all the separate content types 1 by 1).

  • work out specification for the input form structure

    We need a plan to deal with the changing of the form field labels based on the publication type.

  • Develop a technical spec for all the content types

  • porting of the content types to CCK

  • updating the data manipulation functions

    Biblio has built in functions to pull data from different sources, these data collection functions will have to be updated

Helping out

If you are interested in being part of a code sprint for CCK Biblio add your name to the list:
-Pronovix team - Kristof Van Tomme and Ernő Zsemlye
-Agaric Design Collective - Benjamin Melançon
-True Wheel - Mark Lilly (drupal id: marqpdx)

Other people that are involved in the discussion are:
-Ron Jerome
-Stephane Corlosquet
-Robert Haschke
-dayf