[development] Limited hierarchy generations in Book module

[andrew morton]

I'm not sure how easy this would be to do because the book module uses
the menu system for it's hierarchy and the menu system has a hard
depth of nine. It definitely won't change in D6 but you make a good
case for an adjustment in D7.

andrew

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