[development] object.module - part 4

[Edgar Whipple]

[Continued from part 3]

I said a previous followup that I think we really can make everything a
node. I wanted to add a bit about why I think so, and about what some of
the implications of my pre-roadmap concept might be.

However, I covered in a separate post much of what I had in mind, under
the subject "Everything's a node != Everything's in 1 table". So
instead, I'll talk here about the effect my ideas might have on
module-level developers.

(Some of this isn't entirely consistent with my previous posts. Please
excuse that; I'm thinking out loud here.)

I mentioned that I think there should be a unified API for handling all
node types, which includes all the "metatypes": content nodes, taxonomy
vocabularies and terms, users, and all the rest. The example of various
modules proves that any of those "non-content" types can in fact
represent content. Therefore, they should be nodifiable.

But, I don't think module developers should be forced into thinking of
all different node types in identical conceptual terms, and I certainly
don't think the users should have to deal with it. So, here's an idea on
how to avoid that.

As I mentioned elswhere, for $node_type = 'mynodetype', these two
function calls have the same meaning:

  node_create($node_type, $field_values_associative_array);
  mynodetype_create($field_values_associative_array);

So, define default CRUD handlers that everyone can use, and declare them
automatically for every new node type component. (The possibilities of
_how_ are several, so I won't go into that here.) 

By simply, say, adding a line to my_module.info like:

  module_type = MODULE_NODE_TYPECOMPONENT

I get a full set of default handlers with *my own* module's name on the
functions. That means developers can think in terms of
taxonomy_term_create() and custom_contenttype_delete(), without having
to think much about how they're implemented using the same API's and the
same storage engine.

Then, perhaps by adding a couple more lines:
  
  api_overrides = API_NODE_DELETE, API_NODE_VALIDATE
  api_extras = myfunctionname, myotherfunctionname

all sorts of possibilities open up. The developers can introduce
whatever high-level functions they need, in a standardized and robust
way, and without complicating low-level data handling any more than the
absolute miminum necessary.

CONCLUSION

My point is that nodifying everything, with all the benefits that go
with that, doesn't need to make Drupal any harder for ordinary
developers to wrap their brains around. We could, in fact, make it
easier, *if* we are sufficiently willing to distill truly flexible,
powerful back-end API's and their implementation.


In Part 3, I mentioned an idea for a new module installation model. I'll
describe that idea further in my next and final followup.

This, however, concludes my basic proposal.

-Edgar Whipple
drupaladmin at misterwhipple.com
www.misterwhipple.com/drupal5 as soon as I copy the data to my hosting
account.