Book module break out features
Jeff Eaton and I had chatted about book module off and on for the last month when in Dries 'state of Drupal' presentation he mentioned some of the same things as well. At the code session I hunted several people down and tried to come up with a task based list of steps to get book module to the 'next' level for Drupal 6. So here's the break down, if no one has any objections I will file them as separate issue's. Separate outline out of book/book content type and make a legacy content type called book for migration purposes. Allow for multiple root books with their own permissions and /menu blocks Allow for next/prev automatic links on/off for a given book yes this can be done through the theme but a switch would make it more accessible Versioned pages for each book which affect the tree - support branches/tags to allow for selecting which branch you want to see. User input multiple relationship (on page or displayed separate block) Menu system allows you to split menu's into multiple navigation blocks. Look at integrating book module to register it's menu's with the menu module to create per book modules into the menu system. (per Dries) This would also bring it more in line with other core modules. Allow for a given node to be tagged for more than one hierarchy Use vamcode for the module (per Dries)
On Tuesday 27 March 2007 11:26 pm, Steven Peck wrote:
Jeff Eaton and I had chatted about book module off and on for the last month when in Dries 'state of Drupal' presentation he mentioned some of the same things as well. At the code session I hunted several people down and tried to come up with a task based list of steps to get book module to the 'next' level for Drupal 6.
So here's the break down, if no one has any objections I will file them as separate issue's.
Separate outline out of book/book content type and make a legacy content type called book for migration purposes.
So this would be a "Value-add" module in the style of OG, Event, etc, so any arbitrary node type can be pulled into a book?
Allow for multiple root books with their own permissions and /menu blocks Allow for next/prev automatic links on/off for a given book yes this can be done through the theme but a switch would make it more accessible Versioned pages for each book which affect the tree - support branches/tags to allow for selecting which branch you want to see.
Would this be different than revisions? Is this to replace the Drupal 4/5/whatever taxonomy category used on d.o? If so, how do you handle paging? If you're on page a.b.c, in the "Drupal 5 branch", and the next page link is to page a.b.c.d, does the branch carry over? How do you handle the case that a.b.c.d has no Drupal 5 branch? If you can make it work, awesome, but I am wary of the complexity here.
User input multiple relationship (on page or displayed separate block)
Menu system allows you to split menu's into multiple navigation blocks. Look at integrating book module to register it's menu's with the menu module to create per book modules into the menu system. (per Dries) This would also bring it more in line with other core modules.
With menu 6 pushing everything into the database rather than an obscenely large array, that should solve most of the performance issues. However, what would the performance penalty be if we were to get up to, say, 50,000 or 100,000 book pages? I don't know an answer here; I'm just thinking aloud. :-)
Allow for a given node to be tagged for more than one hierarchy
It would need to have a "primary hierarchy", in case you went to the page directly. You can guess next/prev when paging through a book should follow the "active" book, but not if you go to a page directly.
Use vamcode for the module (per Dries)
Questions aside, I think this is highly cool. :-) -- Larry Garfield AIM: LOLG42 larry@garfieldtech.com ICQ: 6817012 "If nature has made any one thing less susceptible than all others of exclusive property, it is the action of the thinking power called an idea, which an individual may exclusively possess as long as he keeps it to himself; but the moment it is divulged, it forces itself into the possession of every one, and the receiver cannot dispossess himself of it." -- Thomas Jefferson
-----Original Message----- From: development-bounces@drupal.org [mailto:development- bounces@drupal.org] On Behalf Of Larry Garfield Sent: Tuesday, March 27, 2007 10:05 PM To: development@drupal.org Subject: Re: [development] Book module break out features
On Tuesday 27 March 2007 11:26 pm, Steven Peck wrote:
Jeff Eaton and I had chatted about book module off and on for the last month when in Dries 'state of Drupal' presentation he mentioned some of the same things as well. At the code session I hunted several people down and tried to come up with a task based list of steps to get book module to the 'next' level for Drupal 6.
So here's the break down, if no one has any objections I will file them as separate issue's.
Separate outline out of book/book content type and make a legacy content type called book for migration purposes.
So this would be a "Value-add" module in the style of OG, Event, etc, so any arbitrary node type can be pulled into a book?
No. Any content type can now be pulled into book. Right now book content type is old style non-cck type. It needs to be changed to the new type.
Allow for multiple root books with their own permissions and /menu blocks Allow for next/prev automatic links on/off for a given book yes this can be done through the theme but a switch would make it more accessible Versioned pages for each book which affect the tree - support branches/tags to allow for selecting which branch you want to see.
Would this be different than revisions? Is this to replace the Drupal 4/5/whatever taxonomy category used on d.o? If so, how do you handle paging? If you're on page a.b.c, in the "Drupal 5 branch", and the next page link is to page a.b.c.d, does the branch carry over? How do you handle the case that a.b.c.d has no Drupal 5 branch?
If you can make it work, awesome, but I am wary of the complexity here.
Yes interesting question. It's a like to have from my point of view. Jeff Eaton had a thought it could be done. Robert Douglas has a contrib. module that has revision tagging that may Provide one avenue.
User input multiple relationship (on page or displayed separate block)
Menu system allows you to split menu's into multiple navigation blocks. Look at integrating book module to register it's menu's with the menu module to create per book modules into the menu system. (per Dries) This would also bring it more in line with other core modules.
With menu 6 pushing everything into the database rather than an obscenely large array, that should solve most of the performance issues. However, what would the performance penalty be if we were to get up to, say, 50,000 or 100,000 book pages? I don't know an answer here; I'm just thinking aloud. :-)
Well, that will be interesting but frankly book module needs to be brought into line With the tools we have in core and get rid of this little independent oddity. I suspect the performance issue will be better than current book module. The other Problem this solves is the current block pain. If you have more than one book, You only have ONE block. So all your book table of contents are required To be in the same spot in your theme unless you do really weird theme things
Allow for a given node to be tagged for more than one hierarchy
It would need to have a "primary hierarchy", in case you went to the page directly. You can guess next/prev when paging through a book should follow the "active" book, but not if you go to a page directly.
Maybe a 'default' initial 'old style' hierarchy but I don't see why it needs an Ultimate fallback once people begin have multiple 'root' books. Single root or the first book would mimic the current behavior.
Use vamcode for the module (per Dries)
Questions aside, I think this is highly cool. :-)
-- Larry Garfield AIM: LOLG42 larry@garfieldtech.com ICQ: 6817012
My goal was to break it down into separate tasks that people could accomplish. To more likely get people to work on it and get accepted this time around. I don't think I myself can learn PHP fast enough. :) The last try at this was one humongous patch that scared people. SO this is hopefully a series of achievable steps to bring book module up to current standards. I have a tentative commitment to try for some of this but will wait to see If we have any other hand wavers out there. I will make the issues tomorrow Unless there is additional feedback. Thanks, -sp
Op woensdag 28 maart 2007 06:26, schreef Steven Peck:
Allow for next/prev automatic links on/off for a given book yes this can be done through the theme but a switch would make it more accessible
Did you consider sticking the next-prev-up links and the index (list of children) in blocks? With the regions (content region), and default-settings in a module, it will appear to Joe User as if nothing changed, while you had a huge amount of power to themers. And you set the first steps in a direction of much more consistency, and an actual web-based layout system. Next step could be to e.g. put breadcrumbs or pager links in blocks too. Just my €0.02 Bèr
I thought about wether it would be a good idea or not to use the (new) menu system as a base for all this [hierarchical page structuring module, iow. book module], as the menu system already provides the basic data structures to construct a hierarchy/tree. If the menu system would be the base, things could look like this: * each 'thing' in the tree is represented by a menu item * the book module takes care to keep nodes and their menu items synchronized * the module provides a simple form that can be added to other forms, for example to the node creation form (we have this already, but the I could be improved) but also to e.g. the views creation form, to create a new menu item * the module also provides a simple book (= special menu trees) managment UI * the module provides a per-root-menu option wether navigation links (like in the old book module) shall be displayed or not [as per berkes' suggestion: in a block that is placed in the "content_bottom" region by default] * Breadcrumbs are taken care of by the menu system The advantage would be that you would then have a page hierarchy that can include all types of pages and not only nodes. I'm not yet totally sure wether this could work out, I just wanted to throw in the idea... - so - what would be the advantage of maintaining a second structuring/tree table with just nodes instead of improving menu.module, and giving it a book-module like UI (maybe additionally to the classic menu UI)? regards, -- frando (originally posted as a comment on http://drupal.org/node/128731) Steven Peck schrieb:
Jeff Eaton and I had chatted about book module off and on for the last month when in Dries ‘state of Drupal’ presentation he mentioned some of the same things as well. At the code session I hunted several people down and tried to come up with a task based list of steps to get book module to the ‘next’ level for Drupal 6.
So here’s the break down, if no one has any objections I will file them as separate issue’s.
Separate outline out of book/book content type and make a legacy content type called book for migration purposes.
Allow for multiple root books with their own permissions and /menu blocks
Allow for next/prev automatic links on/off for a given book
yes this can be done through the theme but a switch would make it more accessible
Versioned pages for each book which affect the tree - support branches/tags to allow for selecting which branch you want to see.
User input multiple relationship (on page or displayed separate block)
Menu system allows you to split menu's into multiple navigation blocks. Look at integrating book module to register it's menu's with the menu module to create per book modules into the menu system. (per Dries) This would also bring it more in line with other core modules.
Allow for a given node to be tagged for more than one hierarchy
Use vamcode for the module (per Dries)
participants (4)
-
Bèr Kessels -
Frando (Franz Heinzmann) -
Larry Garfield -
Steven Peck