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.
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:
This integration question has been coming up frequently (some are duplicates):
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.
- a diagram of the current database tables and inter-relations
- link to CCK Doxygen documentation
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
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: