I've remained a quiet observer so far in this discussion, mainly because I'm well aware of Dries' opinion on the 'everything is a node' idea. But now that the discussion has moved away from 'nodify', I think it's safe to join in. :P I agree that creating a new 'base object' in Drupal is an excellent idea, and one that will seriously improve Drupal's ability to share more functionality between more parts of itself. I would suggest calling the new base thing an 'entity', rather than an 'object', though. The category module, which I wrote, implements the 'terms and vocabularies as nodes' idea. I wrote the category module because I wanted to do things with categories that are not available in the taxonomy module, but that are built in to the node system (and the book module). What I did was a hack, but it was necessary: however, I will be very happy if Drupal is improved so that this hack is no longer necessary (although I have my doubts about a 'base entity' being able to completely remove the need for the category module). As the author and as a heavy user of the category module, I have found that it's very useful to have these features (and more) shared between the node system and the category system: - body text (filtered) - commenting - versioning - adding CCK fields - displaying lists with views - metadata (e.g. author, created/updated time, published, promoted) - hierarchical (i.e. parent-child) relationships - display of TOC and prev/next links (for hierarchical nodes/categories) - tagging (i.e. ability to tag categories with other categories, rather than just tagging nodes) - automatic URL generation with pathauto - more powerful theming, e.g. per-content-type theming, CCK field theming So, if we develop a new 'base entity' for Drupal, then I would like to see everything in the above list be moved from the node system to the base entity, because everything in the above list is useful to share between (at the very least) the node system and the category/taxonomy system. Honestly, from looking at that list, you may be thinking what I've thought all along: "if you want to share that many things between nodes and categories, why not just have categories as nodes?" Which is of course why I wrote the category module in the first place, and why I still think that it was a good idea to do so. Also, regarding the point in my list "hierarchical (i.e. parent-child) relationships", it would be great if this new 'base entity' incorporated the idea of a 'relationships API' that various people have been talking about. Because relationship handling is a feature that needs to be shared between the node, category, and comment systems, and most probably between many more. And regarding the points in my list about CCK and Views: I think that one of the key aims of this 'base entity' idea should be to allow CCK and Views to 'move up the chain', so that they can be utilised by ANY entity within Drupal. If you think that adding custom fields to your book reviews is cool, and that displaying your mom's cooking recipes in a custom list is cool, imagine how much cooler it would be if you could add custom fields to e.g. your site's comments, and if you could pass your site's users into a custom view listing! People think that CCK and Views are 'killer modules' now, but they're nothing compared to what they would be if Drupal allowed them to break out of being node-centric. These modules are too important to be tied down to the node system: they need to be 'services' that are available anywhere and everywhere within the Drupal entity model. Cheers, Jaza. On 1/21/07, Nedjo Rogers <nedjo@islandnet.com> wrote:
Dries wrote:
there might be room for a light-weight container object, that both nodes, comments, users and taxonomies extend from.
Agreed, this is a much more promising approach than what I outlined--and proof once again that some quick, sound advice from the dev list can save a lot of useless coding :)
So I'm seeing two stages to implementing this.
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.
object.module or object.inc has methods similar to our current ones: object_load(), object_save(), object_delete(), and uses a hook_object() similar to our current hook_nodeapi(), hook_user, and hook_taxonomy() set. The object methods call any implementations specific to the type. E.g., object_load() invokes a function $object_type->name .'_load'.
2. Having reworked our existing object handling to extend a base object, we then look one by one at the systems currently specific to nodes and consider attaching them to the base object instead, so that they still apply to nodes but are also applicable to other object types. E.g.:
* node_access table becomes object_access, and gains a field, type_id (object type). * Current nodeapi modules could be optionally rewritten as hook_object implementations, so that they can attach their behaviours to any object type. * Possibly, node_revisions becomes object_revisions.
Does this sound right? Doable? For 6.0?