[development] object.module (was nodify.module idea: 'everything is a node')

[Jeremy Epstein]

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 at 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?
>
>