Roadmap
The categoryi module is a great and useful tool already, but that doesn't mean it can't be better! We refuse to rest from development until it washes your car for you, cleans out those smelly bits of goo from between your toes, and serenely massages your aching body according to the traditions of the Japanese Zen Shiatsu discipline. What all that means, in a nutshell, is that the module still has a long way to go.
This section exists in order to document future plans for the category module. If you wish to develop a new feature, you can add a child page here, and describe your plans for what functionality it will have. Anyone who creates a page in this section should update it whenever new developments occur, so that visitors to the site can track the status of future features.
How far from the Drupal's taxonomy we are?
2 years ago, I found Drupal and thought it must be the best choice for CMS, but finally I found no way to effectively create my customer's corporate site which is likely a catalog of products, service, plan, events, and news, rather than blog, news, members and portal site.
Flexinode answer a part of the requirement. Taxonomy, that Drupal guy said is one of best parts of Drupal (I have read somewhere about the idea of creating Drupal), is not powerful enough. I agree with you about the weakness of Drupal. (But I did NOT say that Drupal is bad. It's really one of the best I know.) At that time, I went back to my good old framework and forget Drupal for years.
Today (actually a few weeks ago that I came back to drupal.org again) I found a new module that could answer my need. After trying the Category module for days, I agree with many developers that this module should be included in Drupal as a core module. Thanks for makeing it.
That's what I want to tell you but found no place to post because many posts about this module have been closed and the rest are about bug reportes, patches. Hope this place is relevant to my comment. ;)
Currently, I have an issue to ask you. Basically it comes from trying to create a web site with this module, but finally it may lead us to the conceptual design that the module grounds on. The issue is how to easily categorize contents by their properties? Imagine that you have a catalog of cars with many properties such as color, engine, type, year of manufacturing, size of tires, etc. to present in list of all or grouped into each properties. What should I use, between CCK fields or Category or any other module?
If I use only Category, all the properties will be shown as terms near the title while not in the content like normal properties. If I use both CCK and Category (by using node reference field to node that is categoryi), I will have to select 2 times for each property. Or I should use CCK and View rather than Category?
I am thinking of something that combine together the CCK, Category, View and something like dynamic query, to play the contents better. However, this idea comes from db-driven or schematic content point of view, which may be far from what Drupal bases on.
If this requirement is able to be done easily by the existent module, please suggest me. If not, could it be possible to make something to solve this issue? soon? ;)
PS: Should we try looking at the shared containeri like a query of nodes which is the intersection of multiple properties (queried by AND of many properties.) It is a view from a db-oriented developer.
Torwards a Hybrid Future
Quite clearly, the Category module is a brilliant effort. Containers and Categories being nodes is absolutely the way it should be. Any node being able to act as a categoryi or containeri makes perfect sense to me (being an OO developer, without much web site experience). The foundations for a rich future are here, and I agree whole-heartedly that Drupal should embrace the category module for its future.
Now, having said the above, I must make the following observation. I went through the hybrid tutorial. I still haven't completed it. I am a fairly hardcore OO developer, but at 2:00 A.M. I couldn't take it any more. :) I have to confess, from a site "power" contributor's point of view, this whole hybrid structure implementation was an "icky bit," not just the hidden containeris.
This observation has lead me to two suggestions for the future of the Category module, the first specific, and the second general:
1) Create a category_hybrid module, or something to that effect, that simplifies this process so that the structuring part tends more to the "zen" side as does the final ui. I read in the comments a question regarding "what if the topics were the same for "news" and "blog." Couldn't they use the same hierarchyi? I didn't do any analysis of your answer, and I know nothing of the code structure, but I do know from OO design principles that they absolutely should be the same entity. One shouldn't be maintaining the same topic in multiple places. Perhaps you can find a way to hide these icky implementation details (hidden containers, admin titles, duplicating category hierarchy maintenance, having so many attributes to check in a sea of attributes), and provide a simplified interface when building these hybrid structures. Perhaps this might cause a rethink of the system in general, and another layer of abstraction somewhere. However, my gut tells me that the foundation of the Category module is so sound and well-thought out, that such an abstraction will fall out with just a little thought. If this hybrid structuring is as valuable as you say it is (I am no web designer, but I can certainly take your word for it), then such an effort would likely be worth it, and further, would probably lead to future structuring simplicities not yet imagined.
2) The general suggestion: Whenever the building of a highly useful structure, from Category module Lego blocks becomes as "icky" as this hybrid structure appears to me, an abstracted module should be implemented to handle the icky stuff transparently. (Perhaps I am stating the obvious)
Perhaps another way to say what I am saying is that if you want to really sell the Category module as the future of Drupal-- and I agree that it should be-- then your showcase tutorial should be a quick implementation that doesn't make your head spin, and also leaves you with a zen ui. A zen implementation to a zen ui. I am sure that you need a tutorial showing the building from scratch of complex structures-- but not as your main intro. I am guessing that most people implement web sites in Drupal to avoid dizzying details. I know I do, and I am a fairly decent software developer (although not on the web side so much).
Highlight things like the fact that Forums, now being a node, can have their visibility controlled by access control. Under today's drupal, without categories being nodes, I can't hide a forum, only its posts with access control. I don't want anonymous users seeing my Site Administrators forum.
Also, another suggestion just came to mind for a tutorial to sell this. Have a transition tutorial that shows how easy it is to build sites and categories like you would in Drupal without the Category module. Again, maybe you need a new module for this, that limits the noise of all the choices when adding what is equivalent to a term. After all, adding a vocabulary or a term is pretty straight forward in Drupal. You almost want to have this capability as a starting point. If you don't have this its going to be hard to move the whole community to the Category approach. You need an upgrade path that is as painless as possible. (Not just the conversion utilities, but the UI components two!)
The bottom line, though, is that the Category module is a beautiful thing! I don't want to implement a Drupal site without it.
Christopher C. Mills (Chris)