[development] hook_foo() vs. nodeapi

[Jeff Eaton]

I was VERY skeptical about the CCK-driven future. I had a chat with
JonBob about his 'vision' for the new system, and if I understand it
correctly, he's working towards something like this:

CCK 'field types' are specific kinds of data, like URLs or images or
large blocks of text or numbers or dates.
CCK 'widgets' are UI elements that edit those pieces of data (like a
dropdown list of user accounts)
CCK 'content types' are defined collections of fields, with the settings
regarding which widgets should be used to edit them. (One field type may
support numerous different editing widgets for different UI needs)

Aggressive use of caching would reduce the performance hit for loading
content types defined in this way, just as caching today speeds up the
loading of node types that have many corollary tables added via nodeapi.

A module that defines a new content-type would just expose a blurb of
metadata that describes the content type in terms of fields, widgets,
etc. If it needed special kinds of fields or widgets, it would implement
those as needed. This would be a lot like views.module, and how it
handles custom data, custom field definitions, etc. Modules would still
be able to expose custom handling code to impose additional validation
rules, post-processing, etc. But a world of additional possibilities
would open up; users who need a custom field or two would be able to
simple *add* those fields to 'blog' or 'page' using the CCK
infrastructure. No custom code needed.

I'm probably not explaining it very well, but after my conversation with
him, I was convinced. I think it has a LOT of potential.

--Jeff


-----Original Message-----
From: Khalid B [mailto:kb at 2bits.com] 
Sent: Sunday, May 07, 2006 5:43 PM
To: development at drupal.org
Subject: Re: [development] hook_foo() vs. nodeapi


On 5/7/06, Larry Garfield <larry at garfieldtech.com> wrote:
> This seems to echo the "why make nodes when you've got flexinode" idea

> that was floated a while back.  The answer then and now being "because

> sometimes I don't want my data's definition and structure in the 
> database, I want it in code where I don't have to do everything twice 
> between a beta site and live site."

Here is an idea: I would call "portable node definitions".

This can be some sort of predefined node data that would make a fresh
site have the new node types.

These can be some sort of metadata file, and can be as simple as some
PHP code that does that, or can be Yet  Another Metadata Proposed
Format.

This way, instead of having a classified or job search module, we would
have a metafile for each, and that is it.