Jump to:
| Project: | Category |
| Version: | 4.7.x-1.x-dev |
| Component: | Miscellaneous |
| Category: | support request |
| Priority: | normal |
| Assigned: | Unassigned |
| Status: | closed (fixed) |
Issue Summary
With regard to http://category.greenash.net.au/node/102#comment-47, is there any reason why someone using category module, especially on a fresh site, would need to use these query operators at all? This has been baffling me for quite a while and I think I am missing something in my understanding.
One of the differences in approach I notice between taxonomy and category is that, in taxonomy, you only need to create your vocabs and categories once and then use query operators (with their own disadvantages) to get listings of union and intersection (ughh..are they both the same?) nodes. For example, if I have News, Events, Stories and Images as main site sections, I can have just three vocabs such as Programmes, Years, Topics (each with its own categories) and then by using either query operators or the views module, get listings such as:
News
-News by programmes
---Health Care
---Welfare and Relief
-News by topics
---Capacity Building
---Skill Development
Events
--Health Care events
--Welfare and Relief events
Images
--Images by Programmes
---Health Care Images
---Welfare and Relief Images
--Images by Year
---2006-2007
---2005-2006
---2004-2005
--Images by Topics
---Capacity Building Images
---Skill Development Images
Success Stories
--Success stories by topics (with child cats)
--Success stories by programme areas (with child cats such as Health Care stories etc)
--Success stories by year (with child cats)
Of course, getting these into menu blocks or a hierarchy or the right breadcrumbs is a nightmare if you use the taxonomy module, even with any number of helper modules.
By contrast, these things are "oh, so easy" in category, but it seems (with my limited understanding) that I should use either category_views (again, quite tedious to build each view, although this is not the category module's fault) or create these as separate containers and categories (News by programmes, with its child categories) to get them to automatically appear in the site hierarchy, menus, breadcrumbs etc.
So, I guess I see the value of category (not that I ever doubted it!) and in essence my questions are:
- Is my understanding about the difference in approach between taxonomy and category correct?
- Do query operators have any role if one is using the category module?
- Which is better- using category_views to generate the kind of menu blocks and listing pages for union and intersection of nodes that I want or using simple containers and categories (slightly more work than the taxonomy approach, but less than building category related views)?
I will be happy to write up a few book pages if these issues can be clarified.
Comments
#1
The query operators are still available in category, but there's no particular reason why you need to use them, if you don't need to show unions or intersections of category node listings. As for the question of query operators vs category_views - I haven't really considered that before! I guess that category_views can basically do the same querying as the category/taxonomy query operators (in fact, it is much more powerful - it can mix AND, OR, and NOT operators, plus do additional filtering). So it's a matter of personal preference, and it depends on which features you need - e.g. if you need the very customisable display options, then I guess you'd use views (and/or category_views).
#2
Thanks, Jaza. I too felt that category_views was much powerful than the query operators. If you will excuse me, I would still like your opinion on the following:
As many of the sites I work on are quite complex, I often have a need to show unions or intersections of category/taxonomy node listings. I find that, for this, the typical taxonomy approach results in fewer vocabs. I know one can do the same in category also, but it appears to me that its general approach (as outlined in the hybrid tutorial) is more in line with creating the results of unions and intersections as containers and categories.
In effect, this more or less means having the results of unions and intersections as categories to be tagged when creating a node, thus resulting in more containers and categories than the taxonomy approach. I don't have a problem with this (because of the many advantages that category brings), but I just want to know if my conceptual understanding is correct.
#3
If you just want pages that display intersections or unions of categories, you can create a view by itself, just using the views module, and not tied to any particular category/container with category_views. The only purpose of category_views is to embed a view on a category page as an alternate style of node listing. If you don't need this, then there's no reason to use category_views - you can just use views that aren't embedded within category pages.
#4
Thanks, Jaza, for that tip about plain views vs category_views. I remember reading it before, but sometimes these finer points go right over the head unless someone reminds.
Thanks for your patience in answering these support queries.
#5
I'm trying to figure out how this query thing works, but I don't seem to have the same paths as I should have in order for the queries to work:
My paths still say "/node/155." This may be because I have the i18n module installed, but I'm not sure. Is that what it is? In any case, can I still use the category module for category intersections or will I have to install views to get it to work?
#6
Quick answers:
1.) category_pathauto is broken as of now. That may be why you are not seeing aliased paths.
2.) If you are looking to display the node teasers of *all* categories within a container on the container's page, just set the depth of the container to a negative value, say -1