[development] Limited hierarchy generations in Book module

[Athanasios Velios]

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