Please consider adding an option to present a collapsed menu, showing only the top-level terms, as the initial presentation. This would be useful to minimize the page space taken up by the initial presentation of large taxonomies. All other functionality would be preserved, i.e. node counts, if enabled, would still be displayed for the top-level term; clicking on the top-level term would result in the same presentation as occurs now, etc.

Under current code a collapsed initial presentation can be achieved by manually disabling the child branches of the generated menu, but with large and dynamic taxonomies this is an impractical and error-prone maintenance task for the administrator. A collapsed presentation could be achieved if the code would, when the proposed option was selected, still generate the child branches but set them to "disabled" by default. Deselecting the option would rebuild the menu and enable the child branches.

Comments

rcrowther’s picture

rcrowther CreditAttribution: rcrowther commented

This request, little and reasonable in itself, is the tip of an iceberg, or an analogy I would prefer, one of those tree stumps that that will take three weeks to dig out.

Brieflly (I'll expand if anyone likes). To gain a consistent admin presentation, I've aimed to get menus working on pages AND in blocks. To get them REALLY working on pages, with a true backtracking breadcrumb, means having an altered URL. V3 could do this - it had full expanding menus with a backtracking breadcrumb, and it opened in a 'closed' manner, which is pretty much how it should be, and I think includes what you wish for here. Unfortunately, that was about all that V3 could do, and when it arrived as V4 the extended URLs users complained like crazy - in retrospect, I was not in a position to support them, and how could they gamble rebuilding their entire site (to the weird long URLs) in the hope the module was a solution?

V5 went backwards to the point of innovation, by playing nice with the URLs that already exist, and this has proved popular. I then tacked on the ability to use a URL with a menu name, a neat halfway house that offers some styling possibilities and a few other things. But the power of the treebuilder, to deliver V3 true paged menus (something other modules don't really do) is not tapped yet.

From the development perspective, I'd like to work on the generalized solution. But if the issue piles up, I'll look at quicker fixes.

If we are talking about DHTML menus, I am very stuck. DHTML menus work from a full menu tree, and this module is delivering that. V5.3 of DHTML Menu, with no warning, took a wicked development swing. I've stayed abreast, and will always endeavor to stay abreast, as it is a critical priority, but I have no idea where they are heading next.

BayouBill’s picture

BayouBill CreditAttribution: BayouBill commented

I don't understand all your reasoning, but that is only because I am a new user of your project, never experienced the older versions, and still don't understand all the jargon. I have also never used the DHTML Menus module. I will try to dig in and gain a better understanding of your reasoning, but for now, I think that what I need could be accomplished relatively easily by doing what I suggested in the second paragraph of my original post - generating the branches but marking them as disabled. The tip of the iceberg is all I need to do the initial presentation of a lengthy taxonomy in as little page real estate as possible.

rcrowther’s picture

rcrowther CreditAttribution: rcrowther commented

I lurched into thinkin' there.

You'd like an option to hide terms, by default? (A Drupal oddity - called 'enabled' on the menu display, called 'hidden' in code). So you can build up the display, rather than trying to knock chunks out of a large taxonomy menu?

How urgent?

(gist of the long post - if that's what you are needing, I'd like to do this the big way, but that will take time and thought)

BayouBill’s picture

BayouBill CreditAttribution: BayouBill commented

Not urgent, but would like to have in a month or two if doable the "easy" way. Here's why I want it:

When this project goes into production, I'm going to have a fairly extensive vocabulary, with something like 200 top-level terms and probably 50 or so second-level terms, all of which will have multiple parents at the top level (see the diagram in my initial post at http://drupal.org/node/558202 for a very simplified example). Assuming each top-level term shows just 5 second-level terms as descendants, this results in a treemenu with 1,000 branches! Imagine how long the initial page will be, or how many pages this will require(*). (This is one of the reasons I asked for http://drupal.org/node/563140.)

But users of the system won't really need to see all the branches (descendants) in the initial presentation. All they'll need to do is see the top-level terms, and be able to click on a top-level term and then see the same thing as what results if they do that in current code. Translated into the lingo of the actual project: "Click on your location, and we will show you what you need to know."

(*) The Readme says, under Things taxonomy-treemenu can do, "Has a pager.", but under Things it can't do, it says "The page function will not page menus. Which is to say, if your menu is very big, the module will not clip it, but push the display off the screen.". If I display the treemenu on a page rather than in a menu, which statement applies? (Sorry for the laziness, but I haven't actually grown my test taxonomy enough to find out.)

Hope that 'splains things.

rcrowther’s picture

rcrowther CreditAttribution: rcrowther commented

Good oh, think we know what we are after.

Got me on the documentation! Has a pager (for term lists) but no paging for a menu on a page (niether has Drupal, and I think it would be kind of tough - the pager is a bit of a marvel anyhow, then they'd have to glue it to this module's ability to break menus up, all the while maintaining level of depth across the different pages...). So your concern is generally applicable - unless there's a way of cutting menus down, a big taxonomy (not broken into smaller bits, but that's plainly not a way to go with your site) has no facilities for squashing.

I'll try and figure out my way forward then. Right now I'm battering against the translation problem.

BayouBill’s picture

BayouBill CreditAttribution: BayouBill commented

"Right now I'm battering against the translation problem."

No problemo. Set your own priorities and "do what you gotta do" (is that in a Dr. John song somewhere?).

rcrowther’s picture

rcrowther CreditAttribution: rcrowther commented

Thought I'd tag this on.

I've had a couple of personal messages about the module. Yeah, they should be here on the issue list, but I do sympathize with people stumbling round computing culture while trying to get a job done.

The gist of it is this - has Treemenu stopped doing what V4 did? Could it start doing it again, please?

In this case they mean the 'expanding menu' feature, so I'll start explaining my home-brew terminology....

The Drupal navigation menu, I call an 'expanding' menu. That is, it starts with just the base terms, collapsed. As you press on terms, those terms open up, and others on the same level collapse. Then a user can 'drill in' to their interest.

At the moment, Treemenu only delivers what I term 'stiff' menus. That is, the menu as you have defined it is all there, at once. But V4 could do expanding menus. I backed out of this because V5 was such a massive re-write. Anyhow, Treemenu has a commitment to 'stiff' menus, because if you use the DHTML Menu module, that's what it needs to work (when a user doesn't have Javascript, the menu then degrades to the full 'stiff' menu, which is kind of nice).

So why do folks want the 'expanding' menus back? Because if you don't use DHTML Menu, you'd still like expanding menus, because they save a massive amount of screen space (think of Drupal's navigation menu, and what it would look like if it opened fully expanded, or, scary now, it was a View).

Current top priority is a big internal rewrite on the link creation engine. Since this affects areas such as access and URLs, it's going to need a lot of testing and bug squashing. Fortunately ('fortune is the residue of design' Spencer) the rest of the module is in a good way and I'm making progress.

After that, while it is not the complete answer to these issues, (See BayouBill's post here) expanding menus are the number 1 priority.

wallbay1’s picture

wallbay1 CreditAttribution: wallbay1 commented

You should really have an option to only show parent categories . It make sense
and the user can click on the parent then it will show the subcategories. or can you point me in the right direction on how to do that?

rcrowther’s picture

rcrowther CreditAttribution: rcrowther commented

Hello wallbay1,

Better than that, I think. Try the new version 7, and enable 'expanding'. Most cases, you'll get expanding menus in blocks (barring multiple heirarchies - check the menu status display). Then, if you want that on a page, enable 'use mlids for page urls' or whatever I called that option. You'll get a fully expanding menu, just like a navigation menu, on a page.

I agree with both yourself and BayouBill that these are necessary features for working sites. The problem is the distance you have to travel in code, which why you will not find features like this in other modules/other systems (yeh, I've never seen this on ANY website?)

This is brand new, and the help hasn't been written yet. But comments welcome.

rcrowther’s picture

rcrowther CreditAttribution: rcrowther commented

I should also have mentioned - you could use DHTML Menu - that's two solutions. Me, I'm a big fan of JavaScript, but maybe not so much in these situations, where it involves huge chunks of website operation. Probably not a solution for a larger site, but it looks very dandy. Your choice...