Posted by narres on March 1, 2009 at 5:24pm
Overview:
Enhance the taxonomy system with node functionality like: Author, Timestamp, Status (Published, ...)
Description:
According to the old discussion that "Everything is a node (users too)" this will help in a lot of common (to be solved) problems.
Hav e alook at Everything is a node discussion, especially:
Why taxonomy:
* The taxonomy builder becomes a streamlined interface to both build a tree of terms (nodes) and select an item from that tree to classify a node
* Both the tree and each classification can be designated using relationships
* All the taxonomy storage and retrieval functions can be encapsulated by the relationship API
Mentors:
- narres - will help with defining todos
Difficulty: medium
Comments
Sounds cool. How would this
Sounds cool. How would this differ from the Category module?
Chris Shattuck
Learn Drupal with over 1700 Drupal video tutorials
The difference between this and category.module
category.module is (as far as I know) a complete replacement of taxonomy.module (core). It uses own data structures (mainly nodes), too. That makes integration into views and cck-taxonomy much more harder.
Integration with other modules like similar_content, tagadelic e.g. is much more difficult.
Advantage of category.module is the easy use of nodes as vocabs (that's the other direction of vocabs with some additional info).
Disadvantage: It's not lightweight. Think about some 100K nodes and some 10K vocabs. This will slow down your system.
Since you don't want to vote (e.g) on vocabs, storing taxos as real nodes has to much overhead.
So I thought "just" about enhancing the system taxonomy.module by an add-on, which is storing:
in additional colums or a seperate table.
Since this is fast done, the main task is to:
Actually, Category had an
Actually, Category had an option to store its data in taxonomy tables. It also had its own Views integration.
I used to like using Category module because you could make taxonomies, and each term would have a node that you could edit, and it could generate book-like navigation to show its children terms, or attach a view.
It was pretty powerful but ultimately pretty buggy, as well.
Sure, but what happens if
Sure, but what happens if you are movving Vocabs with taxonomy_manager.module or creating new Vocabs with autotagging?
Are there new book-nodes created too? My last (maybe obsolete) test says: No.
In fact category.module is a real nice tool I'm using for some special interest, but it's (imho) to mighty for "just" adding a few additional stored informations.
Is this still valid with fields in core?
Isn't the idea of fields in core that we don't have to make everything a node, but can still have the functionality that would come with making something a node?
Maybe a good project would be to add field support to taxonomy? Taxtonomy.module hasn't gotten a lot of love in a long time, so there's likely a ton of work to be done in the area.
--
Alex Urevick-Ackelsberg
ZivTech: Illuminating Technology
Alex Urevick-Ackelsberg
ZivTech: Illuminating Technology
You are right. Maybe this
You are right. Maybe this will end not in an own project, but in support fields in core for D7. But that doesn't matter.
Since code freeze for D7 is 1st September the timeline will fit.
Taxonomy fields module?
How close does the Taxonomy fields module come to delivering this?
http://drupal.org/project/taxonomy_fields
Cheers,
Bill
FunnyMonkey
Click. Connect. Learn.
Using Drupal in Education
FunnyMonkey
Taxonomy_Fields brings just
Taxonomy_Fields brings just normal Taxonomy and CCK closer together (and ist nearly out of maintenance since there is no D6 version?). In D6 everybody is using http://drupal.org/project/content_taxonomy instead of this (I think).
The closest (IMHO) module to the task is http://drupal.org/project/taxonomy_access which adds User- and Accessrights-information to a Taxonomy and Vocabulary.
The core task is to add
information to taxonomy.
I may just be dense, but I'm
I may just be dense, but I'm failing to see how adding UID, Dates, and Status to terms and/or vocabularies would be useful. Taxonomy is mostly used for labeling and categorizing content, right? Could you give examples of how someone may use this information?
From what I can tell from "Taxonomy Access Control," it doesn't really add access rights to terms and vocabularies, but stores and looks up access information based on terms in it's own table to see if the content should be accessible. It doesn't make sense to me for labels to have their own dates, status, and users associated with them.
Taxonomy is more than just tagging content
Taxonomies are a tool for building generic structures like hyrarchies, networks, cross-references and connecting these to nodes (or users via additional modules).
Practical use (just a few examples) of:
-- If you decide to "blacklist" a special term you could do it easily with a state
-- Detect old terms wich are obsolete for deletion
-- Additional rights management
To me this seems almost
To me this seems almost completely redundant with term references as fieldable entities in D7.
Not using fields to describe these properties /might/ mean a small performance gain over fields.