[development] Limited hierarchy generations in Book module

Nathaniel Catchpole catch56 at googlemail.com
Sat Feb 7 20:48:09 UTC 2009

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.

If you want fast handling of hierarchy in Drupal 7 without limits, the
number one place you can help is at http://drupal.org/node/344019 - which
would add a very advanced method for storing trees to Drupal, and also make
it pluggable with different methods from contrib.


On Sat, Feb 7, 2009 at 7:28 PM, andrew morton  wrote:

> 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 < 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
> >
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.drupal.org/pipermail/development/attachments/20090207/9769601e/attachment-0001.htm 

More information about the development mailing list