The biggest complaint I have with the book module (which I love, by the way) is with assigning weights. I simply cannot remember what weight I assigned every individual page in my (rather large) book! Therefore I must edit another book page, just to see it's weight, then go back to the first page, and change it accordingly, so that they will appear in the proper order.

This is especially noticeable with user submissions. While an ordinary user can submit a page and decide on it's parent, they cannot put it in its proper order. I must again edit other book pages to see their weight, so that I can properly position the new page.

This patch appends each page's weight next to its title in the "Parent" listbox, which is just above the "Weight" listbox. This change allows those with proper permissions (i.e., "administer nodes") to quickly reference the different page weights and make the appropriate selection. The weight does not appear if the user does not have the "administer noted" permission.

This patch also adds to the description of the "Parent" listbox, describing the addition. This added description is only visible to those with proper permissions, and does not affect the original translatable description.

This seems to be a helpful tool to any site coping with a large number of book pages.

CommentFileSizeAuthor
#2 book.module.weights_added_0.patch1.63 KBcoreyp_1
book.module.weights_added.patch1.52 KBcoreyp_1

Comments

chx’s picture

chx commented
Status: Needs review » Needs work

Idea: +1 . Complaint: there is no problem with a string change, do that instead of the concatenating here.

coreyp_1’s picture

coreyp_1 commented
StatusFileSize
new book.module.weights_added_0.patch1.63 KB

As for the concatenation, I was trying to consider the scope of my changes:

  • In breaking the description into two parts, the original translation will probably be available, even if the new addition is not.
  • In the event that this "mixed translation" happens, the concatenation assures that the main content will be understood to those making the changes.
  • It is shorter (translation-wise).

Then again, perhaps the overhead of concatenation, function calls, and complexity outweighs these points.

Here's a patch for the other way.

moshe weitzman’s picture

moshe weitzman commented

i suspect that most book authors don't care about weight and just use alpha order. so this patch adds clutter. anyone else care to comment?

urbanfalcon’s picture

urbanfalcon commented

Actually, there probably are many instances where alpha order aren't applicable. Think about picking up a novel at the bookstore...are all the chapters in alphabetical order? Sure, you could number the titles, but that's a really backward way of getting what you need...not to mention very messy. You could leave "holes" in the weighting order for future chapters to be included...how do you do that with a numbered title system? Skip from "chapter 1" to "chapter 4" ? That would look dumb, and fixing it would involve re-titling a bunch of documents. I haven't tried either patch version, but it's definitely worth a look.

Jaza’s picture

Jaza commented
Version: x.y.z » 6.x-dev

I like the idea of making the weights of adjacent book pages more visible, when adding/editing a book page. But wouldn't it make more sense to make it visible on the book editing form, rather than on a viewing page? The user needs to know the weights when they're actually editing. I think this patch should make the weights shown in the 'parent' select box on the book editing form, instead of in the TOC of book pages.

Moving to 6.x-dev queue.

chx’s picture

chx commented
Version: 6.x-dev » 7.x-dev
Jaza’s picture

Jaza commented
Status: Needs work » Closed (fixed)

Mouldy issue. Closing.