Posted by Merlin on Wed Feb 15, 2006 11:14 pm.
When I first downloaded and installed Drupal, I did some of the usual things. I installed the blog module and forum module and played around with them. After about 5 minutes of playing I turned off blog.module. Too restrictve. Did its thing its way and that was pretty much it. Didn’t seem like anything I needed, and really, I don’t think it seems like anything anybody needs, except maybe in a couple of particular situations.
When I played with the forum—and later the image—modules, I realized something interesting. This ‘great and powerful tool’ that many people define Drupal with, Taxonomy, was being used not to classify, but contain.
Forums, really, are giant containers. You have a bunch of posts in a forum, and you can have forums within forums. But really, with Drupal, you have a bunch of posts that are basically tagged as being in a given forum. This has some interesting side effects. The first one being that the classification system effectively breaks down. Because the classification system is being used to contain the posts—and put them where they belong—it means that using it for other things can be cumbersome. See my previous post about node access, for example.
The way (I think) this really should work is that the container should be an object. This is how book.module works, in fact. Doubly, in fact, this is how category module works, which is an interesting solution. I’m not convinced it is the right solution, but I haven’t fully played with it to see how it does its containing. But let’s take a second to look at what I think is an ideal.
In my world, A blog is a container. It contains posts, and it has some data on it. For example, it knows who owns the blog. It knows who is allowed to post in the blog. And it knows who is allowed to read the blog. And finally it knows what kind of posts the blog can contain. As a user on the right system, I go and create a blog, and I get back a container. The container has a few options — view the blog, edit the blog, post to the blog.
I can post any type of node I can already post into the blog. Images, Stories, Cars, whatever node types exist on the system that the blog will allow me to post. When I make a post, I attach it to the blog — presumably through something that makes it easy (post to this blog link, for example), and the blog takes care of the rest.
Forums are almost exactly the same, except that some of the defaults are very different. Forums tend to have much wider permissions for who can post, and they need people who can moderate. They have a more interesting set of access requirements, in effect. And forums can contain other forums. There is absolutely nothing wrong with this relationship, except that it’s somewhat difficult to express in a relational database. But that’s what the lineage nonsense is all about.
Incidentally, it then makes much more sense for containers to worry about the security of the items they are in than it does for taxonomy to worry about it. That lets taxonomy return to its original purpose: Classification. Tags, for example, shouldn’t really be nodes, at least I don’t think. But there are some systems that are complex enough that they do—I think, however, that really gets us into another area of containers that operate similarly to forums, but perhaps with slightly different requirements.
CCK makes all of this a lot easier, I think, and Views handles a great deal of the work as well. Between the two, an actual module has very little real work to do — mostly handle the minutiae of permissions and enhancing the presentation to meet the requirements of the container.
This is a very object-oriented philosophy, but it’s one I think works very well.
(It’s worth nothing that comments really become child nodes of another node—another container model).
Books are already most of way there, except for the problem that there isn’t really a specific book container. Note that container doesn’t necessarily need to be an object type, but more of an object setting. But in general, books are an excellent example of one specific implementation of this general concept. Much of that implementation can, and should, be generalized out, so that forums, blogs, books and other similar models can all use the same basis, and each have their own individual needs addressed.
Ber made a modification of
Ber made a modification of blog.module which I think does what you want:
http://cvs.drupal.org/viewcvs/drupal/contributions/sandbox/ber/blog/
I also agree with this approach.
forum too
and someone did forum as container so that any node type can appear in a forum. i can't recall who did it. he was also involved in some i18n stuff i think. not jose.
you see, there are no new idea in drupal, just need people to follow through on their experiments :)
akvaforum
here is a link to that alternate forum module -http://cvs.drupal.org/viewcvs/drupal/contributions/modules/akvaforum/
Yes we do...
http://paul.leafish.net/articles/drupal/blog_blog
Event approach
Your 'generic container' approach sounds very much like the approach taken by the event module. An event is not a node type, but rather a set of properties that can be applied to other nodes (of any type). So a story can be a story node, plus it has event properties. Same for image, poll, blog post, etc.
Maybe this is the approach that the category module should be taking. Instead of 'category' and 'container' node types, maybe category information should simply be extra properties of other node types. But then again, category essentially does this already, with its outline feature (which it inherited from book module).
Drupal has a lot of powerful hooks, such as nodeapi, that make it possible to extend other ndoe types rather than creating your own. If modules started leaning towards extending other node types, I think this would be taking Drupal in a good direction.
Terminology and containers.
Merlin,
Your description helped me to understand better the various "entities" within Drupal (or at least what ideally they should be). As discussing about concepts may help for building a better site (or an even better Drupal), I would like now to expose how I see all this.
I agree with you when you say that a blog, a forum or a book is not a node type (Images, Stories, Recipes, ...). I would add one node (one post) is an instance of a node type. My_image_43 is an instance of the node type Images. And I could say also my_blog is an instance of the container type Blogs. For me a container type is a "publishing mechanism". In fact I don't like the word "container" (something like a box, a storage, a bag where a node is put; in one and only container). I would prefer the word "channel": as one says "I got this information by a different channel (TV,radio, newspaper, chat, ...). A node will be published trough one (or more) channel. As far as I know "channel" in not yet a buzzword in the CMS world but here at least I will use it.
An administrator (site designer) creates node types (using CCK for example) and channel types (among other things). Basic channel types may be provided by the core like front page; others are build using various means (enabling modules, custom themes) according to the site purpose. These channel types generally add new properties to the node type (for example "promote on front page", "add this to my blog" checkbox or "my parent node is this one and I have this weight"). There is no necessity to explain to the user what channel is implied for a given property (a view can decide which set of properties will feed a channel). Properties are not all related to channel types (for example "comments allowed" or views bookmarks does not imply a priori a given type of channel). Channel types are not the only mechanism for presenting/filtering/ordering the information (Taxonomy/Category or Node_acces may be other mechanisms for organizing the information).
An author creates nodes. For each node he chooses the node type which can carry the content he wants to add to the system. Then in that new node (new instance), he writes/composes/uploads that content (which has no influence on the "publishing mechanism": a change in the content will be reflected as is, in the node). He also sets the properties (which influence the way its is publish: changing a weight, a date will certainly have an effect in the node presentation).
A reader selects a channel (with may be some arguments like in John's blog or in a search). The build-in logic (the corresponding channel type) extacts/filters/orders the needed nodes from the database and file sytem according to their properties. The result is presented (theme, CSS) to the reader.
For the time being channel and channel type are just "conceptual entities" which already help in the design/documentation of a CMS or site. You would like that channels become objects: "Assign a node to my_blog". Why not. We don't have yet a flexichannel module to try that ;-). But who knows (CCK?).
@Jaza: I don't like either the usage of the word container in the category module. Because as said above it looks like a box, a storage, a bag without any organization. I would prefer frame ("an arrangement of structural parts that gives form or support to something; a structural unit on or in which something rests" from my Webster's Encyclopedic dictionary). I know "frame" is already used in the Web world but it is difficult to find other terms more appropriate: scheme? outline? skeleton??.
@Merlin: Finaly after proposing frame to Jeremy, it seems now even better, more generic than channel. Anyway I understand that container is (like class, type, module) a very generic term that helps to explain things. Sorry if I mixed up a well established teminology.
The term 'container'
Indeed, you remind me that developers often get wrapped up in their own terminology. A container is a term for an Object Oriented construct, and it really means anything that resides within anything else. Boxes and storage lockers are also containers, but very often the parent-child relationship is a container, especially if the primary way of locating that child is via the parent.
It is true, though, that the container relationship is merely one of many relationships--it is just one of the most common seen in information organization, and needs to be one that is very easy to utilize.
After writing all I have
After writing all I have written above, I realized that your terminology was certainly the most appropriate when discussing with others. I am from the old school (I passed my computer science thesis in 1977). Object Oriented proramming was not yet born and I am now rather illiterate in that domain.
Taxonomy: A container, a classification system, and an object
First, I agree with several of your points:
However, I fail to see why taxonomy can't be a container/object AND a classification system?
Counter-argument: Taxonomy can be a container for many types and also a way of classifying nodes.
My basic premise is the orthogonality of vocabularies allows terms to serve as either containers or classifiers without interfering with each other. This is based on the observation that when classifying nodes, one is, in effect, placing those nodes into containers.
Let N be a vocabulary used for site navigation. N is a required, multi-select, single inheritance vocab (though these properties are not required for my point to be true). Let N have the following, hierarchical terms:
Let C be a vocabulary for classifying nodes. C is multi-select, non-required, non-hierarchical. Let C contain
In this scenario, "blog" postings can be placed into the "blog" container, and classified with any number of classifying terms (e.g. happy + wet + green). Similarly for forums, news stories, etc.
As to the data in those posts, they can be images, text, whatever - as the container (taxonomy) is generic (unlike the old blog module).
Access control can be provided by a taxonomy access system. There are at least two implementations so far. While neither is perfect for every task, between the two of them, one can do most of what you want regarding ACLs.
As a someone who "likes to write APIs and tools", I would suggest you turn your attention to improving the taxonomy API and related modules.
If views + CCK = 90% modules, then views + cck + taxonomy = 90% of sites. Improving the taxonomy system to fully provide containers is the way to go.
1) The hierarchical taxonomy
1) The hierarchical taxonomy classification system is difficult to maintain. It's especially difficult in the current system to have a term that is owned by a user. I can't currently think of a way to do this, and taxonomy_access doesn't do it.
2) In order to achieve the kinds of things I like to see, the manipulation of the taxonomy system does a lot of work do do away with the basic interfaces (Forum and Image galleries, for example, provide their own interface to taxonomy).
3) Controlling which taxonomy terms appear can be difficult. Yes, taxonomy access can do this, but without ownership of terms, right now you get nothing but role-based permissions. "My Blog" should be long to me, dammit.
4) A taxonomy term itself isn't really an entity. If anything, it's just a flag that happens to have a little metadata. Adding to that meta-data ends up creating something that's kind of like a node, but isn't. Why not just have a node?
5) Because of 4), when doing a 'drill-down', where depth is completely arbitrary and you can have data at any level, it's nigh unto impossible to mix a display with data + terms. Example: I have a hierarchy of information for Geography. I have terms like Geography => United States => California => Northern Californa => San Francisco/San Jose Bay Area => San Jose => East San Jose
When each of those are terms, there isn't really much metadata about them. But when each of those are container nodes, I can add metadata all I need, and the container areas can appear in my hierarchy right in there with "Peter's Bakery" in East San Jose and keep a nice, easy to use interface into drilling down to more specific information.
6) The code in views.module for taxonomy is a nuisance. Admittedly, much of this is simply because of the way hierarchy works, but ugh.
Everything I've talked about turns out to be possible today, and I've got a pretty good start on it. Views was recently extended in a way to provide a lot more support for the drill-down concept, and I've got some code that will allow multiple node access modules to share data, making it actually easy to create access modules that only control a particular section of the universe.
I happen to love your use 'C' and I even love hierarchical implementations of 'C'.
(Example Food => Chinese => Szechuan) -- classifying something as Szechuan implies Chinese and Food.)
But for containing, I think it's silly. My biggest gripe? When posting to a forum, you're presented to a bunch of places you can't post to. With 4.7 it's fixable using form_alter, but I'm just not fond of that solution.
1) The hierarchical taxonomy
As to access control, TAC lite should help with this. As per my response to our other conversation, ownership can be implied by edit/create/delete permissions. If you are referring to other UI issues with maintaining hierarchical taxonomies, I'm all ears.
Agreed. This is a huge pain and needs to stop. Now.
Taxonomy allows a module to "own" a vocab, but all it does is store the module's name in the table. It does not change any behavior depending on who owns the module (taxonomy or module_x).
Taxonomy really needs a better API: a better way to create, modify, and display vocabularies outside of the adminstration tools taxonomy provides. More important: taxonomy needs to handle module vocabs differently than taxonomy vocabs. For example, here's a patch I submitted to do some of that. It would address some of Ber's comments to the devel list today.
Yes, but I think my answers to 1 and 2 should provide some solutions for this.
I disagree. It is an entity. It does not have a great API, but it is a first class citizen of the Drupal world (though it is shackled to a second-class API right now). If I had my way the basic buidling blocks of drupal core would be:
but I digress....
It sounds like you are hinting at the Category or Tagnodes modules. These maintain 1:1 relationships between terms and data nodes. I think they are the solution to the problem.
Improving node access is a good idea, regardless of taxonomy or taxonomy access's shortcomings.
I tend to think of content in a drupal install as points in a high dimensional space. Each axis of the space is a vocabulary (or other meta data - author, date, other stuff hardwired into nodes). By keeping vocabularies orthogonal, data can be located in this space by referring to it's coordinates (vocabx, vocaby, vocabz, author). Collections of content are hyper-planes where some of these coordinates are held fixed (vocabx = 'term 1', author = 'joe'). By providing structure within the meta-data you can get interesting implications (szechuan => chinese => food) or (noodles => (chinese OR italian) => food).
In this paradigm, containers should just define what coordinates are fixed and hold some of their own metadata.
After writing this post I guess I have come to the position that it is time to write Taxonomy2. I have some more immediate goals, but I think the time is right. We need a taxonomy system that is equally well designed for modules as it is for users.
Funny
What's funny is that category is much more to my solution which basically does away with taxonomy and promotes the whole thing to nodes. Except I think a node is overkill if you're just tagging/classifying, but perfectly what you want if it's containing.
Extending
I thought category extended taxonomy, not replaced it.
I am not saying that additional data is bad, nor that we should not provide the mechanisms to store more meta-data for nodes. These sound like good goals.
I am advocating that these systems use taxonomy at the base, so that they can interpolate with each other better.
As an example: Currently, workflow stores its states in it's own data structure. For all intents and purposes, a state in a workflow and a term in a vocabulary are absolutely equivalent. But because workflow does not use taxonomy terms, I cannot limit access to certain workflow states using the existing taxonomy access modules. Instead, I have to set up a parallel vocabulary that mimics the workflow, and a series of actions that move nodes from one taxonomy term to another. These tasks are administration nightmares.
Conversely, if workflow stored it's states as terms, it would be trivial to use the taxonomy access system to limit access to nodes as they travel through the workflow. Editors have access to "under review" nodes. Everyone has access to "published" nodes. Etc.
If organic groups used taxonomy to mark it's nodes, it wouldn't have to be a node access module! How great is that! Organic groups would work with workflow. The list of benefits goes on and on.
The reason this hasn't happened is because taxonomy does not have a good API and is not designed to be manipulated by modules. If we can change these two things, the real benefits of taxonomy will quickly be picked up by module writers.
Post new comment