Limited hierarchy generations in Book module
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
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@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
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. Nat 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
Quoting Athanasios Velios <a.velios@gmail.com>:
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.
For outlining I like to use the node relativity module [1]. It allows you to bind other nodes or create new nodes as children of a parent node. The UI of the node display provides a menu of the children and parents. A node can be a child of more than one parent. [1] http://drupal.org/project/relativity -- Earnie http://r-feed.com Make a Drupal difference and review core patches. -- http://for-my-kids.com/ -- http://give-me-an-offer.com/
participants (4)
-
andrew morton -
Athanasios Velios -
Earnie Boyd -
Nathaniel Catchpole