The current menu system method of handing hierarchy, materialised path, has to had a hard depth (not necessarily 9, but something). Taxonomy doesn't have a hard depth, but it's also very inefficient to do any queries based on depth in taxonomy module.<br>
<br>If you want fast handling of hierarchy in Drupal 7 without limits, the
number one place you can help is at <a href="http://drupal.org/node/344019">http://drupal.org/node/344019</a> - which would add a very advanced method for storing trees to Drupal, and also make it pluggable with different methods from contrib.<br>
<br>Nat<br><br><div class="gmail_quote">On Sat, Feb 7, 2009 at 7:28 PM, andrew morton <span dir="ltr"></span> wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
I'm not sure how easy this would be to do because the book module uses<br>
the menu system for it's hierarchy and the menu system has a hard<br>
depth of nine. It definitely won't change in D6 but you make a good<br>
case for an adjustment in D7.<br>
<br>
andrew<br>
<br>
On Sat, Feb 7, 2009 at 2:15 AM, Athanasios Velios < wrote:<br>
> Hello,<br>
><br>
> I am a little confused with the limitation of 9 generations in the<br>
> hierarchies of book structure in D6. Such limitation did not exist in D5<br>
> and relevant discussions have taken place here:<br>
><br>
> <a href="http://drupal.org/node/274270" target="_blank">http://drupal.org/node/274270</a><br>
> <a href="http://drupal.org/node/236866" target="_blank">http://drupal.org/node/236866</a><br>
><br>
> Personally I think it is not reasonable to assume that every drupal<br>
> website will require less than 10 generations in a hierarchical<br>
> structure and I would like to know what your opinions on this are.<br>
><br>
> As far as I can see, there are two arguments for limiting the number of<br>
> generations:<br>
><br>
> 1) Hierarchies without limits can be built with the Taxonomy module.<br>
> 2) Speed when building the menu.<br>
><br>
> Arguments in reply:<br>
> 1) Yes, taxonomy can be used. But then why are we given the option to<br>
> build hierarchies with the book module as well? Why allow two different<br>
> ways of doing the same thing especially when one of them is not quite<br>
> right? The obvious reason is because taxonomy terms are not nodes and we<br>
> want hierarchies of nodes - not vocabulary terms. But why only 9<br>
> generations of nodes and unlimited generations of terms? And yes,<br>
> modules that can link terms and nodes do exist, but they are rather<br>
> heavy and probably risky to use. Also, what happens to backwards<br>
> compatibility for websites that already use the book module for far<br>
> deeper hierarchies? How do they upgrade to drupal 6? Also, the choice of<br>
> 9 as a limit is completely arbitrary. Why not 29 or 39?<br>
><br>
> 2) Speed is a problem which is encountered in every aspect of the<br>
> development. And the answer to it as was suggested in the discussions is<br>
> often caching. Why isn't caching an option here? I do not think it is<br>
> reasonable to reduce the functionality of a module because of this. I<br>
> have also heard that a block with so many generations in a menu will not<br>
> "look right". The answer to this is of course easy:<br>
> a) Why do we assume that multiple generations of nodes will all require<br>
> a menu entry? Maybe navigation is only required to top level children of<br>
> the hierarchy.<br>
> b) Why do we assume that a menu is always in the sidebar (or why do we<br>
> assume that the sidebar is too narrow to fit it). I have more than one<br>
> examples when the "menu" is the main content of a page? And this is a<br>
> theming issue anyway.<br>
><br>
> Also, my feeling is that the major changes in the Book module for 6<br>
> started when a decision was made to combine the code for the book module<br>
> with the menu system. I appreciate that there is quite a lot of code in<br>
> common between these two modules - and excuse my ignorance here - but<br>
> isn't there common code for hierarchy building between the taxonomy and<br>
> the book module? Or at least wasn't that the case in 5? And how come and<br>
> the code for the taxonomy module is free of the 9 generations<br>
> limitation? Why couldn't the book module share code with the taxonomy<br>
> module when it comes to hierarchy handling so that this limitation is<br>
> removed?<br>
><br>
> And as a proposal, in the short term the 9 generations limitation needs<br>
> to be lifted. In the long term, I think a reasonable option would be to<br>
> merge the book module with the hierarchy functionality of the taxonomy<br>
> module. How? By introducing a setting for vocabularies to force a<br>
> one-to-one relationship with nodes. In other words, for a given<br>
> vocabulary, allow only one node to be associated with one term.<br>
><br>
> I have recently joined the mailing list to be able to bring this issue<br>
> up, because I think it is a critical one. So forgive me if this has<br>
> already been discussed and point me to the discussion if this is the<br>
> case - I could not find anything helpful apart from these links. Also,<br>
> forgive me if these ideas sound naive. It would be good to have it<br>
> explained and published out there as other people share my confusion.<br>
><br>
> All the best,<br>
><br>
> natuk<br>
><br>
</blockquote></div><br>