Taxonomy as a field

It's useful to explore how existing core functionality can or cannot be implemented as a field. Doing so may cause us to change how we decide to implement them. In this post I'm talking in terms of nodes but trying to avoid assuming that we are limited to nodes instead of Content objects and that all fields are stored locally in SQL. I'm also mostly just thinking as I go/type; I don't have a specific outcome in mind yet.

Taxonomy is a "multi-valued field" assigned to node types currently via variable settings. The term_node table is effectively a field table: (nid, tid) instead of (nid, delta, tid). One note is that the tid assignments to a nid are unordered whereas field values are ordered. Since the nid,tid order has never mattered before, arbitrarily assigning an order via delta should not matter.

During load, term_node connects to term_data and vocabulary. Observation: Although we wrote down that "drupal_load('node', $nid) will SELECT FROM node + load all fields", drupal_load() probably will not actually load all the data itself directly; instead, it will have to call a taxonomy_field_load() hook. For the specific taxonomy case, perhaps we could encode information in the Schema structure or the field definition that tells drupal_load() to join these other tables. However, consider a field that access remote data (e.g. "Amazon products related to this story" field). drupal_load() can't possibly load that data directly, so we need a field_load() hook, so taxonomy should probably just use it.

term_data contains a term weight which determines the order of tids in the $node->taxonomy array. This is disjoint from the delta column in the term_node field table; the weight is a property of the term, not its assignment to a node. Vocabularies have weights too. taxonomy_field_load() will presumably return an array of field values to be merged into the node. When the node is saved, the taxonomy field table (term_node replacement) will be filled with (nid, delta, tid) but again the deltas will be "arbitrary".

So taxonomy_field_load() turns out to look almost exactly like taxonomy_nodeapi('load'); well, we always knew nodeapi was a pretty powerful model.

Today, $node->taxonomy is filled in as an array mapping tid to an "object" of all the columns of term_data. If taxonomy is a field, then $node->taxonomyfieldname is a field array which means its keys are deltas (in this case, meaninglessly so). $node->taxfieldname[n] is a term_data "object" including the tid. So code that assumes the indexes are tids will need to change to use the tid field directly. Such code exists in taxonomy.module, elsewhere in core, and throughout contrib, probably.

Hmmm. I actually just glossed over something important. If taxonomy is a field type, then multiple fields of type taxonomy can be added to a node. This could be quite useful: "user assigned terms" and "editor assigned terms". However, fields are stored based on their name: $node->usertaxterms, $node->editortaxterms, or something like that. Right now, a node only has one set of terms and it is always available at $node->taxonomy. So if I have a node object I can ask, "what are its terms?" because I know where they are stored. With taxonomy as a field, I do not know where they are stored.

This is not limited to taxonomy; comments are the same way, always at $node->comments but if comments were a field they'd be in $node->commentfieldname.

I think the ability to access $node->taxonomy directly is an historical artifact. Drupal was designed as a CMS and taxonomy, comments, and other CMSy features were built it in fixed ways. Many sites use Drupal for events, and event nodes often have a venue, but we do not expect to be able to access $node->venue to find out the venue for an event node. We have to know the name of the venue field.

What to do about this? Random thoughts:

1. The easy solution: At install time, when we create the 'page' and 'story' type, we create a field of type taxonomy named 'taxonomy' and assign it to those node types. If you create a new node type and want it to play with standard taxonomy functionality, assign the 'taxonomy' field to it. Otherwise, feel free to do whatever you want.

2. Perhaps we need to be able to ask a field type for all of the values on a node from that field type. e.g. $taxonomy = taxonomy_field_all_values($node). Or probably, since the core field registry knows what fields are assigned to each node type, it would be $taxonomy = field_all_values_of_field_type('taxonomy', $node). That would give me all the terms for the node. If I specifically wanted some subset (e.g. only one field's worth of terms), that implies I'm writing new code in a post-taxonomy-as-field world and presumably I know which field I'm looking for.

3. Perhaps what's going on here is that we're trying to turn Drupal into a more general web app development platform and we're discovering that it has aspects of the initial app built on the platform, the CMS app, integrated to deeply into core. The CMS app defines that $node->taxonomy and $node->comment exist as those specific names and then uses them. So perhaps we need to very clearly separate "core Drupal functionality" and "the CMS app" from each other. They can still be shipped in the same tarbar but as clearly defined entities.

All that from "let's think about taxonomy as a field"!