Background Principles
This module ranges over large areas of Drupal to achieve it's ends.
Also, abstract menus have a theoretical background. They are more puzzling than at first apparent.
If you ask the question, "Why can't I build a menu from the Taxonomy?" then you need to try first, and understand the complexities...
However, we have some clear ends,
Links are links
Taxonomy treemenu is about providing a tree structured menu.
If you are hoping for a module like Views, in which a designer can put nearly any site information into a list row,
and features such as visible filters,
this module will not, and never will provide such features.
We have two reasons for this.
-
Views is big module, and demands a lot of memory and some processing power.
To add tree structuring to the lists would overload small computers and client browsers.
-
With current browser rendering, too much information would overwhelm the visibility of the tree structure.
So we stick to a straight anchor links, and the information that can be (reasonably) contained within them.
Help is not something nice you add afterwards
No help is unfinished work. Same as if you wrote the help but hadn't written the code.
There are also some background aims
Try and follow the Drupal method of providing abstract generalized frameworks.
Ocassionally this clashes with Drupal's own implementations.
For example, Drupal makes no provision for menus on pages,
but we treat a menu as an object you can put on a page or in a block, regardless.
Push rendering generalities into the interface
Templates are all very well, and one strength of Drupal is it's massive, overidable templating system.
But templates are essentially a view (the Model/View/Controller paradigm),
and should be reserved for css, and a little fixed HTML.
And there is another issue.
Commercial web designers need a high level interface which they can hand over to their client,
knowing they can guarentee long-term maintainability.
You can see this in the way we offer node ordering in the admin interface,
complementing the forms which core uses for taxonomy ordering.
Find the best method for our ends
This is very evident in the interface.
The module Taxonomy Menu uses a clever trick (building a base menu into the router),
which allows seamless usage of Drupal menu interfaces.
We have different ends, so we use as much of the interface as we can,
but, in use, you will see warning messages and various disabled items.
In code you will find some functions where we walk round Drupal code.
For example, our internal term theme walks round Drupal's term rendering code,
gaining various advantages such as listing the terms in the same order as the menu.
...but use Drupal where we can, and don't drift
We're not going to rewrite the book. Besides, that is harder to maintain.
Sketch out functionality
A (sometimes contentious) principle of Drupal is never to keep backwards compatibility
at the expense of better code.
We do something similar, in that we test out code as we go.
This can lead to dysfunctional code, and a broken user experience.
But it keeps development moving, and we gain a stock of useful code.
Maintain provision for non-Views users
Views is a stroke of genius, but it's not for everyone.
It won't run on small memory machines, and it needs some heft in the CPU and bandwith.
Too often now, designers are using it for small scale uses, to achieve ends they need from other modules.
This module implements such features as the internal theme,
so that these needs can be adressed without Views, if needs are simple.