It seems it doesn't work the way it should...
| Project: | Taxonomy Router |
| Version: | 6.x-3.0 |
| Component: | User interface |
| Category: | task |
| Priority: | normal |
| Assigned: | Unassigned |
| Status: | active |
Jump to:
Hi Rob.
I have two main concerns with the way the router works (you may need to tell me I am wrong):
1. It creates it's own paths.
2. It creates it's own pages for vocabs and terms.
Now I can see why it's been worked out like this - but for me the menu should be using the system paths (or pathauto paths) and the pages for terms that are set up by views (or default).
To me the menu system should be exactly that - a menu. Something which draws a list by itself based on the items already in the database. It shouldn't be adding paths or creating new pages. For it to work with any site the creator would have to solely use taxonomy treemenu for all their navigational purposes and forget about views, and forget about pathauto and primary/secondary menus (all the things that make Drupal great?). Well at least tone down their usage anyway.
I'm probably wrong about that one - it just seems to me that the treemenu is more of a creator than a linker?
#1
Hi there, jptaranto, if you're still there,
You're right, it is to some extent a creator, not a linker. At the moment, it's something of an empty box affair, it soaks up any linkage just looking for the page it is ultimately rendering. The newer version will not, the URL must have a valid linkage, as the newer version (horray!) handles breadcrumbs correctly.
I'm happy to admit I don't know how this could, or might, work with pathauto. The future wiggles it's finger at us.
But this was done for a very, very good reason. Now, I could ignore the path - this module would do its job, print out this menu, highlight/expand, whatever, this item. But the module couldn't underpin treemenu - what if nodes are attached at multiple points in the taxonomy? In other words, the state of a menu is not fully defined until you have the path involved too (thinking upwards toward taxonomy treemenu). And what if we have free tagging? You might use several methods to reach a node - 'vase' might be a 'ornament', or a 'container'. Thus, we have a method for putting paths into the URL.
The module is not adding paths though, none of this touches core. it just tries to understand what you put in as a URL, and put out the page and breadcrumb it can figure out. Dumb. In fact, invalid things won't work properly, and won't work at all in the new version.
Yes, it creates its own pages. I wasn't happy with the initial way I did this, which was based in taxonomy lists, and have veered towards a view which resembles node lists - more consistent with core, and a users visual expectations. Bear in mind that Drupal itself is now agnostic about this - any old page will do, so long as you sling it the right information and it can render it. Taxonomy and nodes already have their own default ways of doing this, Taxonomy router just has another way.
All the templates are over-ridable if you wish. And the views module has been considered. In fact, prototype code is in there, and the page variables (information) have been quite carefully generalized. I've never used views, its a secondary priority, and all commented out, Someday I'll get down to it.
Summary
- This module will soak up any old URL, and give it a shot. So it doesn't generate paths, though I can see how you come to that. It tries to thread through what's there. If it's invalid, the module just returns page failure, and it's getting more stringent about that.
- Yes, it has its own kind of page. That's because niether the taxonomy solution nor the node list solution were quite consistent for a user. I don't see much of a problem there - Drupal does it how it needs for default. Taxonomy Router has already been coded, anyhow, with half an eye on the view module.
Keep truckin'
Rob