[development] "PHP version" taxonomy (and node-type inheritance?)

[Derek Wright]

On Mar 24, 2007, at 1:24 AM, Larry Garfield wrote:

> (I think that can be done with just a taxonomy, but I don't know  
> project module well enough to know if it's a special case where it  
> would need an extra field in the database.  Derek, feel free to  
> thwap me if I just made more work for you. <g>)

a simple taxonomy would do (sort of).  however, i've run into the  
same problem with the "DB support" (mysql vs. pgsql vs. xxx) taxonomy  
term i want to apply to release nodes and/or project nodes: the DB  
support only makes sense for certain kinds of projects (modules), not  
others (themes [god help us if there's mysql-specific code in some  
theme], translations, etc).  likewise, the "php version" vocabulary  
would be meaningless (and confusing) for translations at least, and  
probably themes as well.

<crack-pipe>

speaking of OO ... ;)  wouldn't it be slick if node types worked like  
classes, and you could define a set of node types that were all  
"child classes" of a base node type? ;)  then, we could actually have  
different kinds of project nodes, that were all project nodes, but  
some of them were module projects and others where theme projects,  
etc.  then, you could have a vocabulary (or a view, or anything that  
operates on node types) that points to the "base class" ("project"),  
in which case it applies to all nodes that are of a type derived from  
that type, *or* you could have the vocabulary only apply to certain  
"derived types" ("module project"), not the other kinds of projects.   
each derived type would have all of the node fields defined in its  
parent type(s), plus whatever additional fields you wanted to add in  
the child node type.

</crack-pipe>

back to the question at hand, either we just use a taxonomy that  
applies to all projects and live with the slightly weird UI  
implications, or we do some extra form_alter() work to hide this  
vocabulary under certain conditions, or we come up with a different  
approach for these project-type-specific settings we want.

suggested reading:
http://drupal.org/node/93055


cheers,
-derek

p.s. in defense of my pipe dream, Dries was calling for innovation  
and crazy ideas for core... he was also talking about ways to  
"eliminate the developer".  maybe this isn't one of the "killer  
features" he has in mind, but all of us CS geeks would sure think  
this is cool. ;)  sadly, the amount of code it would require to make  
something like this possible in core is enormous, so i don't see it  
happening for D6, if ever...