[development] The future of hook_node_info()

[Damien Tournoud]

On Thu, May 21, 2009 at 5:26 PM, Daniel F. Kudwien
<news at unleashedmind.com> wrote:
> 3) Make Node API re-usable (like Cache API)
>
> There are many, many, many modules in contrib that could and would very
> happily use "nodes" as storage type and for processing (i.e. load,
> load_multiple, view, edit, insert, update, delete, *_multiple, + being
> fieldable).  But they can't, because we still have a lot of magic happening
> around nodes:
>
> - Nodes appear on admin/content/node
> - Nodes appear in search results
> - Nodes appear on node/add
> - Aforementioned default access permissions
> - Possibly more.

In the "more": nodes have revisions. They have a body in the
node_revisions table.

> What we currently call and understand as "node" is clearly a node of the
> type "content" in reality.

True. Which makes it a little bit less useful.

> Also, considering modules for private messaging or automated feed imports
> that could (re-)use Node API, {node} would quickly become a bloat of
> container for everything.
>
> So lately, I was wondering whether we could open the door to allow modules
> to use the (proven) Node API design by "classifying" nodes and making its
> storage re-usable, _exactly_ like we do it with cache tables already.

What you are proposing is to implement a more generic "Drupal Object",
of which the Node as we know it would be a particular version. That
makes a lot of sense, and would allow us to also properly implement
"set based lazy-loading" one day.

Potential candidates (in core), for such an API (providing life cycle
management and field support for those objects):

 - taxonomy vocabulary
 - taxonomy terms
 - aggregator feed
 - aggregator posts
 - comments
 - url alias?
 - menus
 - menu links?
 - others?

Damien