[development] object.module - part 1

[Edgar Whipple]

This is a followup to Nedjo Rogers' idea about stripping the basic
Drupal object down to the irreducible minimum, then building back up to
current functionality in a cleaner way.

I think that, in order to maximize both simplicity and flexibility, we
need another abstraction layer beyond what you described. It would yield
the logical (and desirable) conclusion to the direction CCK and node are
currently traveling. Specifically, current node "types" are a basic
skeletal node, plus one or more collections of fields-and-functions
slapped on the side. If  on the one hand we we extend your approach by
one additional layer, and on the other hand extend the Drupal-5/CCK
approach to its logical conclusion, it think it will meet in the middle
at a nice universal framework.

My goal is to make all the principles learned from Drupal<=5 as
universal as we (usefully) can.

[This is turning out long, so I'm sending it in parts. If you want to
just skim, read the intro below look for the headings marked LAYER X, in
parts 2 and 3, then skip to the discussions in parts 4 and following]

You [Nedjo] wrote, in part:
> 1. Write a generic object.inc or object.module. Maybe this has two
> tables of its own:
>
> CREATE TABLE {object} (
>  oid int unsigned NOT NULL auto_increment,
>  type_id int unsigned NOT NULL default '0',
>  PRIMARY KEY  (oid, type_id),
>  UNIQUE KEY oid (vid),
>  KEY nid (type_id)
> )
>
> CREATE TABLE {object_type} (
>  type_id int unsigned NOT NULL auto_increment,
>  name varchar(32) NOT NULL default '',
>  PRIMARY KEY  (type_id),
> )
>
> with some initial values default for the object types:
>
> INSERT INTO {object_type} (
>  values (1, 'node'), (2, 'user'), (3, 'comment'), (4, 'vocabulary'),
> (5, 'term')
> )
>
> Every object is now uniquely identified not by a single id but by two:
> the object id and the object type id. Modules can register their own
> custom object_types. Possibly other core drupal objects also register:
> files, roles.
>
I think you're on the right track. Currently, our basic node type is
represented by 'story'. Two data fields, title and body, plus some
housekeeping. More complex node types, like most things out of CCK, add
more fields. Case Tracker, Category , and other modules are even closer
to what I have in mind. The modules don't represent new node types,
although they do include basic example implementations. They do their
real work by defining *type components*, bundles of functionality that
one attached to a basic node-type, making a new, custom type. Because
these "bundles" or type components are orthogonal (read here as mutually
irrelevant), you can combine them many different ways within single new
node type. So, lets universalize that using your approach.

First, I'll describe the layers of software logic I have in mind. Then
I'll describe how what we now call the "core distribution" would become
a reference implementation on top of that logic. I'm not necessarily
suggesting we use this as a design roadmap for the new implementation,
but only as a conceptual tool for discussing and defining the roadmap.

The difference here between my idea and yours is, I had the impression
you were thinking modules would implement specific node types. I think
most modules should be required to provide a *separate*
node-type-component/bundle types, and only optionally provide an actual,
instantiable node type.

I believe your [Nedjo's] table {objects} and the more fundamental half
of your {object_type} correspond to my layers 0, 1 and 2. The more
complex aspects of correspond to {object_type}are spread across layer 2
and part of 3. The rest of my 3, and layer 4, are the part that I think
you may have implied, or at least had silently in mind, but didn't
mention out loud.

[Continued in part 2]