On Thu, May 21, 2009 at 5:26 PM, Daniel F. Kudwien <news@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