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?

> 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
larrygarfieldtech.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-BOUNCESDRUPAL.ORG [MAILTOEVELOPME
NT-
> BOUNCESDRUPAL.ORG] ON BEHALF OF LARRY GARFIELD
> SENT: TUESDAY, MARCH 27, 2007 10:05 PM
> TO: DEVELOPMENTDRUPAL.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
> LARRYGARFIELDTECH.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)
>