In addition to Wolfgang usernode module, there is a node comment module by Robert that just hit CVS last week, which allows nodes (think CCK) to be comments. Everything as node has advantages for sure. Uniformity, generality and abstraction comes to mind.

Dries, You and some others obviously know more than I do about resource use in core, but - it seems that the changes for 6.0, with (as I understand them) node loading mechanism becoming lighter before rendering, might make loading faster - the core code might become more difficult to understand (although I'm not sure why it would, but I'm no core expert), but the API used for contrib modules could actually become simpler, with a slightly reduced number of hooks and no additional parameters, which could make contrib code more easy to write and maintain: CRUD uperations like loading, updating, creating and deleting are already hooked for each of these entities, but in a different way. Would it not be simpler to have the same way be used for each entity ? - you say it does not become easier for users, and this may be true. But it certainly does not become more difficult for them, since most users are not even aware to the "node" term - reducing the number of tables might reduce load (otoh, same-table joins like (content)node->nid to (user)node->nid can be less efficient on some engines), which might indeed be a source of resource hogging, as you suggest. This needs benchmarking, though: this is the only engineering proof. Maybe it has been done at the occasion of one previous discussion on this recurring theme ? Overall though, I have the slightest impression that the rejection of the idea might stem from having from the origin of the software held "nodes" as the basic content entity, wrapped, complemented, and organized by every other entity, and such a change would mean nodes become the basic entity, not only for content, and content nodes become a specialization of this more abstract object, which is another point of view somehow. Note that this would pave the way for interesting evolutions like potential revisions on terms, users and comments (and more). Now *that* would be a major change. Is this also considered when rejecting Nedjo's idea ? Frederic ----- Original Message ----- From: "Dries Buytaert" <dries.buytaert@gmail.com> To: <development@drupal.org> Sent: Saturday, January 20, 2007 11:54 AM Subject: Re: [development] nodify.module idea: 'everything is a node'

On 19 Jan 2007, at 21:31, Nedjo Rogers wrote:

...

Questions: - does this approach sound useful? - who's working on something similar? better? - pitfalls? - anyone wanting to work on this?

I've said it before and I'll say it again; the nodification of such objects is not a good idea for a variety of reasons. Three obvious reasons are: it does _not_ become easier for your users, it does _not_ become easier for the average developer (unless you're a Drupal expert, the code becomes more difficult to understand), and it will be an incredible resource hog.

-1 for 'comments as nodes', 'users as nodes' or 'categories as nodes'.

-- Dries Buytaert :: http://www.buytaert.net/

Aren't we really talking polymorphism here when we say we want to use the something like the node API "toolkit" on other objects? If I read and understand correctly, there are 2 major suggestions. One group wants to make more objects be nodes, so that this benefit is gained. Others don't want some other object types to be nodes and have suggested generalizing the node API to obtain the benefits. Using node-like API functions on other objects sounds like polymorphism to me, which is a "solved problem" so to speak. Any Java or C++ programmers out there who might comment on this? (I only know enough Java and C++ to be dangerous. :-)

Interesting. Thank you for creating the summary table.

Using node-like API functions on other objects sounds like polymorphism to me, which is a "solved problem" so to speak. Any Java or C++ programmers out there who might comment on this? (I only know enough Java and C++ to be dangerous. :-)

the proposed concepts are somehow similar, but there are differents. E.g. hook_form_alter() allows modules to change the node forms. If two modules are changing the form it's still working fine as long as they change two different parts of the form. With OO programming techniques this wouldn't be possible, as module2 would need to subtype the form of module1, which is already subtyping the form. So the hook system seems to a bit more powerful (at least in this case). I like the hook system of drupal, it's easy to understand and flexible. -fago

fago and Victor: I was actually thinking about polymorphism on a higher, more abstract level compared to having an API which can do the same things to a variety of different objects, e.g. nodes, users, vocabs, etc. That is, imagine Drupal to be the virtual machine itself -- and ignore "proper" OO language ideas like class inheritance, etc. Anyway, an interesting comparison nonetheless. Thanks for the follow-up responses.

Am Samstag, den 20.01.2007, 11:54 +0100 schrieb Dries Buytaert:

On 19 Jan 2007, at 21:31, Nedjo Rogers wrote:

...

Questions: - does this approach sound useful? - who's working on something similar? better? - pitfalls? - anyone wanting to work on this?

I've said it before and I'll say it again; the nodification of such objects is not a good idea for a variety of reasons. Three obvious reasons are: it does _not_ become easier for your users, it does _not_ become easier for the average developer (unless you're a Drupal expert, the code becomes more difficult to understand), and it will be an incredible resource hog.

-1 for 'comments as nodes', 'users as nodes' or 'categories as nodes'.

Initially I was also a fan of the "everything is a node" approach. However nowadays I think different. Imo nodes are and should be site content - and nothing else. But people want to use that great tools that are available for nodes for other things too. To break out in this direction, we could generalize the API around all the different things (nodes, users, taxonomy, comments, ..). Such a generalized API would make things a lot easier for developers. I agree with Bèr that there would be need for a such a general "drupal object". So nodes, users, taxonomies, comments, .. could be all such a "drupal object", which all share the same API. With that, tools might become more powerful as they could be written easily to work with any kind of drupal object. @usernodes: The usernode module is useful as it enables views to list users. Also it's useful to theme the user page like any other node. But I don't think users should be nodes - users are no site content. However the user page is or might be - so perhaps this should be a node. Which leads to another point - the user profile: site-content. So perhaps some more things should be a node - or rebuilt as another general drupal object. regards, fago

On 20 Jan 2007, at 12:19, Bèr Kessels wrote:

However, maybe its a bad idea to call it nodifying. Nodes have been serving a specific purpose for too long in Drupal. I guess many developers can no longer see trough the nodes-as-primary-content anymore, and therefore lack the ability to think Out Of The Box when it comes to this.

That way people won't confuse 'general objects' with for example the {nodes} database table. And won't need to wrap their brains around the idea of a 'node beig more then a title+body'. etc. Because right now people often fail to think about the Larger idea of generalised objects, and instead come with arguments like 'but putting averything in a node-table will be bad for performance'. Sure it will, but the whole database architecture is not even talked about, at this point.

This certainly doesn't hold for me. You stop underestimating people's ability to think. :) As you said, there might be room for a light-weight container object, that both nodes, comments, users and taxonomies extend from. It's something I've been thinking about for quite a while. But that's not what FGM proposed, and not what I responded to. -- Dries Buytaert :: http://www.buytaert.net/

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?

I don't like the idea of storing a 'thing' in one table alone. Its not good for performance and horrible when you want to normalise your data. Therefore, I think its a much better idea to go the Active Records route: Define good defaults/standards and provide APIs that can pull information from these standardised tables: drupal_object_load('comment', array('id' => 450)); or drupal_object_load('term', array('author' => 'Joe', 'created_at' => '12-01-2007')); Off course we need to elaborate on all the details and the hows, whens and ifs. But the idea is simple: you define what 'object' to grab. the drupal_object_load will then: 1) look for a $object_name. '_load' function. If exists it will leave the loading to that function. 2) if not exists it will simply try to grab a record from the {$object_name} table. Obviously we need to stick in some more hooks (to let other modules change the objects before or after they are loaded etc) Op zondag 21 januari 2007 03:15, schreef Jeremy Epstein:

- 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

Two more fields, coming from active records (Ruby on Rails) bein *extremely* useful. Especially because in Rails, the Rails core inserts/updates them for you, provided you named them correct: updated_at created_at Furthermore Rails has a very nice way of handling foreign keys (re: that other discussion) also on none-FK-enabled DB engines, by using standardised table and column names (note the plural and singular!) N-to-N tables: terms, nodes. Join table must then be called nodes_terms nodes_terms has columns | id (private key) | node_id | term_id | Active record (Rails) will then sort out the joins for you! without any programming, using only one statement, by the developer. Something like this could be achieved in a simpler, Drupal-way!? 1-N tables: comments, nodes. No join table. comments has, in addition to its private columns one more: node_id. Active record will then load the node with id node_id whenever you load a certain comment. And please, lets not start about wether or not you like RoR, but instead focus on simplifying this idea and boiling it down until it reaches a Drupal-worthy concept? Maybe we should or could have a look at how hooks can solve parts from this? And if it is acutally a Drupal-worthy concept to start with? Bèr -- Drupal, Ruby on Rails and Joomla! development: webschuur.com | Drupal hosting: www.sympal.nl

Am Montag, den 22.01.2007, 09:54 +0100 schrieb Bèr Kessels:

I don't like the idea of storing a 'thing' in one table alone. Its not good for performance and horrible when you want to normalise your data.

I also don't like the idea of a big object table - I just don't see a need for this. I would prefer the pair of type string like node/user/vocabulary/.. with its ID, unique only for its type. I see three pros for this approach: * better performance * easier upgrade from currently existing databases * easier readable object references as you have the type

Therefore, I think its a much better idea to go the Active Records route: Define good defaults/standards and provide APIs that can pull information from these standardised tables

standardized tables are one way. Personally I don't like it that much. I think it would be more visible and flexible, if object type properties are clearly stated somewhere e.g. by a hook which aggregates object type definitions. I also want to point to this interesting issue related to this discussion: http://drupal.org/node/79684 Strategy 3 comes close to the "drupal object" idea. I would go and create the functions drupal_create() drupal_read() drupal_update() drupal_delete() with appropriate arguments. e.g. drupal_read('node', array('nid' => 42)); Then we could go and generalize the node API to work with all drupal objects. But probably it's not necessary or useful to apply the full node API to every drupal object, e.g. the node access system. So perhaps it would make sense that the object type declaring module states, which capabilities the object type has. This could be done with the above mentioned object type definitions, which are parsed from the API. So we could create object types with appropriate capabilities and appropriate resource usage. Basically this is the idea I have in mind, however this needs to be elaborated further. regards, fago

In the discussion of whether everything should be a node, there are two recurring objections. I believe both can be addressed. The 3 numbered paragraphs below describe a data model that responds to the objections. Then, the paragraphs following look at additional implications. First objection is that database performance would be a nightmare if everything were stored in one table. I agree. However, it is not necessary to keep everything in one table. The second objection is stated in different ways, so I'll synthesize: data nodes, taxonomy vocabularies and terms, and other things like comments and users, are all different _kinds_of_things_. It doesn't make sense to treat them the same. I respond by saying that they *are* the same thing: they are data structures with most fields and operations in common. The fact that they don't _mean_ the same thing to us meatpeople isn't relevant to the question of storage and low-level API's, only to the implementation of each type's handler functions. Here's what I have in mind. 1. Put each node type in its own table, and name the table for the type, e.g. {node_footype}. Each node-type table will have columns for the fields that are absolutely universal to all nodes, at a minimum the globally unique node ID, plus timestamps, etc. Note that the node type is not stored in a column in this table, as it is invariant across rows; the typename is implicit in the table name. (In memory, of course, a node's type identifier would need to be recorded.) 2. Each "node type component" that bundles its own fields and defines its own handlers will also have its own table. For example, Case Tracker and Category implement fields and behavior that can be attached to any node type. This one will only have the fields that pertain to the add-on functionality. Again, the type is not recorded in the table data; it is implicit in the table's name, e.g. {typecomp_casetracker}. 3. The fields that are added to the node type's definition individually would be an implicit node type component, so we'll put those in {typecomp_footype}, corresponding to {nodetype_footype}. For example, the fields we would add with CCK, or in a module that defines a complete and independent node type. [Note this implies that node types and type components share a namespace. I don't believe that's a problem. It makes sense for a node type component to have dibs on the base node type of the same name. (If a node type name is already taken, you need to choose a different name for your module anyway.)] So, the definition of a node type is recorded as a type-name and a list of the associated add-ons, the type components. A type component is defined with a name and a list of field names and types, presumably from a catalog of field type definitions recorded elsewhere. For any node type, regardless of the meaning of its data, whether those are content or categories or whatever, the database operations are the same. For example, I want to retrieve all of one node's fields. I the programmer don't even necessarily know what they all are, and I don't need to. (Please excuse my sloppy syntax.) $querytext = 'select * from node_'. $nodetype. ' '; $jointype = 'inner'; foreach( list_type_components($nodetype) as $comp) { $querytext .= "$jointype join typecomp_$comp on node_$nodetype.node_id = typecomp_$comp.node_id". ' '; } $querytext .= 'where blah blah whatever' If the fieldnames are encoded from the type component's name, e.g. my_component_name.text_field1, the developer will never need to know or care about the storage mechanism, as all he'll ever give or get is an associative array. Each type component's handler would add/remove/whatever the node's ID and type to an index table owned by that type component. This takes care of the case where we want to manipulate a node or nodes from the database without knowing their type, and that's when we want to work with all of one metatype (taxo term, content, etc.). For each metatype, create a node type component that's exclusive to it, and *POOF!*. All the semantical differences among node types take care of themselves in the naming conventions, and where necessary in the handler functions. I believe this mechanism might allow us to avoid the major database performance issues, particularly the self-join problem. It should also simplify the engine by merging all our current data-metatypes into only one basic abstract type with one API, without introducing confusion for the module-level developers. -Edgar

On Mon, 2007-01-22 at 20:48 -0600, Larry Garfield wrote:

And right there you lose the ability to treat a node as "just a node", because the node data is so spread out. You can't easily "find all nodes created after time X", because there's n different tables you have to search.

I think I would tend to disagree. Yes, you need to load from the database a definition of each node type. However, you only have to do that once per node type, not once per transaction. Once you have that type definition in memory, you can build a single query for your node operation, regardless of how many tables the node data are spread out among. I'll offer a refinement of my previous example for illustration: function retrieve_newer($nodetype, $cutoff_datetime, $comparison='>=') { $querytext = 'SELECT * FROM node_'. $nodetype. ' '; $jointype = 'INNER'; foreach( list_type_components($nodetype) AS $comp) { $querytext .= "$jointype JOIN typecomp_$comp ON node_$nodetype.node_id = typecomp_$comp.node_id". ' '; } /* etc. */ return $resultset; } The developer/user never needs to know about the table structure. All he needs to know is the type identifier, or even just a type component identifier. For SELECTing node data, he gets all the fields together, and when he refers to $mynode[component_name][field_name] he'll get the fields he wants. The only way he wouldn't is if he asked for the wrong node type, and that's hard to do in this example. (As I mentioned previously, you would never even want a node's data without having at least partial knowledge of its type.) So, we'll have *at most* one query per node operation--less with lists of nodes--plus one query per node type per bootstrap. (We may be able to eliminate the latter. I'm about to post a proposed module loading scheme that could reduce or eliminate those.) Now, this does imply a separate query for each node type in any list of nodes. I think maybe we could work to improve even that with the right join setup, but even if I'm wrong, one query per node type ain't so bad.

And of course, I'm seeing a trend toward more CCK-esque nodes, which means fields get split out into separate tables to allow for richer data types and multi-value fields. That complicates things in an entirely different way.

Again, I believe I may not agree. Assume we require that *all* node fields be bundled up in the named groups that I called "node type components", and in the manner of modules like Case Tracker or Category. Assume also that each type-component has its own table, with the relationships I described before. Then, simply by knowing either the node's type identifier _or_ the identifier of any of the node's type components, we have full access to all of a node's data, *even if* we don't have full information beforehand of its type. _Complexity_ becomes much less of an issue at the module-development level. There is the peformance load of table joins to consider, but I'm not worried about it much. For one, we have that now. For another, perhaps that will be offset by the reduced number of queries involved in a node transaction. -Edgar

Nedjo Rogers wrote:

1. Write a generic object.inc or object.module. Maybe this has two tables of its own: [...] 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. This has an implication that may not be your intention. In my experience, compound primary keys can be a real bear for subsequent programmers. It obfuscates the table relationships, and can make a field look like a key when it isn't. Perhaps it would be better to guarantee that every object's id will be unique, regardless of type. Aesthetics aside, this would also leave the door open for node type transformations.

This quibble notwithstanding, it seems an excellent approach.

INSERT INTO {object_type} ( values (1, 'node'), (2, 'user'), (3, 'comment'), (4, 'vocabulary'), (5, 'term') ) 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 An important point: in the current system, all of these data types can overlap. Users can be nodes using nodeuser; anything can be a vocabulary or a term with the category module. I think this is a good thing, and that the primary reason many people dislike the overlap is that it can't be done very cleanly at present. For this reason, and for the sake of CCK-style type inheritance, I think we need another layer between your 'object' and the entities named 'user', 'comment', 'term', etc. I'll explain in a separate followup. .E.g.: Does this sound right? Doable? For 6.0? I wasn't around for the 5.0 effort. Is it OK that this will pretty much break every existing module? Or, on the other hand, would it be feasible for a legacy-support layer to provide API translation?

-Edgar So, what are the basic

[Continued from part 1] I was saying I believe your [Nedjo's] table {objects} and the more fundamental half of your {object_type} correspond to my layers 0, 1 and 2. The more complex aspects of correspond to {object_type}are spread across layer 2 and part of 3. The rest of my 3, and layer 4, are the part that I think you may have implied, or at least had silently in mind, but didn't mention out loud. LAYER 0 Reduce the fundamental type of storable data to an irreducible "nude node". It has unique, database-specific (non-portable) object ID, the class identifier that you called 'type_id', universal housekeeping info like timestamps, *and nothing else*. This type could be actually instantiated by higher layer's function, if that's ever useful, but the type doesn't actually record any useful data. I'm calling this layer "0" because there's no software associated with it. It's just a principle present in the design of the programmable layers. LAYER 1 This is where we put logic for defining data fields. No actual, instantiable field *types*, just abstract logic--and the API specification--for defining individual fields. That is, their names, their basic database-level data types, their validation parameters or handers, and so on. It would be logically consistent to leave defining basic field types to a bunch of API calls in the reference implementation's installation. And, unless that produces unreasonably long installation times, I think we should, so everyone can see how it works. Perhaps it would make sense to provide predefined primitive field-types as simple INSERT data in the core download, but also provide the programs that called the API to produce that data. (My goal is to avoid hand-written startup data as much as possible.) This will help ensure the core download is entire consistent with the whole design, and it will let everyone see how it was all done, using the concrete example of the reference implementation. LAYER 2 Two logical parts at this level. On the left hand, the mechanism for bundling field types together into the named node-type-components I described above. Specifically, the API at this level lets you gather several defined field types together under a single name, and associate handler functions with it. The basic bundles that we've become accustomed to as Drupal's "built-in" types would be reference implementation, just like the fields for Layer 1. On the right hand is the seemingly unrelated mechanism for actually storing node data in the database. However, these two things have to be together. There's no point being able to store data in the database if you can't define how it's organized. And there's no point defining how to organize data if you can't store that information in the database. LAYER 3 Everything Drupal does could be accomplished with the API layers I've described, but it would be a major pain. The typing would be tedious and error prone, and the learning curve would be too steep. Therefore, it is useful for some node types to have a type-specific API, as they do now. However, it is *not* useful for those API's to all be unique, and it is *not* useful for for every module to have one. This is quintuply true if we really do make everything a module. Many modules operate on only one node at a time, and the standard hooks are fully sufficient. Others, like many of the taxonomy-related modules, require something more elaborate, although we may be able to accomodate that with standard callbacks. And, some of the node types semantics are so different that it's useful to give them special function names, even if what those different functions do is all alike. So, the Layer 3 API will provide tools for defining those higher-level functions. For example, these two hypothetical function calls, with appropriate values, would have exactly the same meaning and effect: <code> populate_node_field($node_id, $node_type, $field_name, $field_value); assign_taxo_term($node_id, $vocabulary, $term); </code> But one of them makes a lot more sense, as users of the current API's can no doubt attest. What Layer 3 should provide is a *standardized* means for defining shortcuts like this, for bypassing standard callbacks with lower-level API calls when necessary, and even for declaring that the standard APIs are bypassed altogether, when necessary. HOWEVER, by using the API to set that up, and requiring that contrib developers do the same, we can some of avoid the horrible database issues and merely-awful-but-bad-enough namespace issues and incompatibility that strike here and there. (Think node-type table name collisions in CCK issues, or [as much as I like the module] trying to integrate just about anything with Category.) The point is, a modules would use *this* API to declare its *custom* API. Ideally, anyone reading it should understand in lower-API terms exactly what that module is trying to accomplish, without having to grovel through the implementation of that custom API. (Some of this layer's "API" might really just be further deveopment of the current .info file requirements.) I think this is also the appropriate layer of abstraction for the API's for admin pages, input filters, and a lot of the stuff that happens outside of actual nodes. (But not all; I think you'll be surprised.) LAYER 4 Layers 1 through 3 create the engine. Layer 4 is where, in a very real sense, we create Drupal itself. These are the high-level API's that module developers declare using Layer 3, and possibly using the lower layers. That's both the high-level API's for Drupal's core node types, and all the contrib modules' special-purpose API's (*when needed*, and we need to be strict about that). A side note: Some of my words might seem like a call to do away with the hooks API. I do, in fact, think the hooks idea should be reexamined, if only just in case something better presents itself. However, I'm not advocating a change like that here. I believe this model will accommodate the hooks structure. More importantly, I strongly believe that this approach will facilitate creating a legacy-support API that fully implements the hooks system for the benefit of D-5 modules. LAYER 5 There is no layer 5, unless you want to count printable documentation. :-D Part 3 of this <ahem> manifesto will describe examples of using this approach, Part 4 will look at some implications for contrib-level development, and Part 5 will go into the new module-loading mechanism I alluded to. [Continued in Part 3]

[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@misterwhipple.com www.misterwhipple.com/drupal5 as soon as I copy the data to my hosting account.

Brilliant! This unified CRUD interface with custom non-CRUD handlers (and the rest of your proposal) describe a good implementation of the vague ideas I've been having about the Drupal database for a couple years, or so. There are many side benefits to this sort of architecture. ..chrisxj