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...