(I asked local Drupal person Mike Gifford about a much more ambitious version of this recently and was told it would be difficult to get everything I wanted, so I'm going to back off on my requirements and see what happens. And if it's cost-effective, I'm happy to pay a local consultant to give me a hand just to make sure I do it right. Currently running Drupal 6.17 on my website, just so you know. Am also not even close to being a Drupal expert.)
I want to write courseware manuals that are both entirely readable online and, when I want, I can -- with one click -- send them to the printer in preparation for handing them out to students for a class. So those are definitely two different issues.
First, the sort of content I'm looking to put into a course manual will look a lot like a sample wiki page of mine, say, http://www.crashcourse.ca/wiki/index.php/System_calls. Nothing difficult or obscure, it's going to be lots and lots of source code, so that page is a pretty good representation of what the content will look like.
As for the manual structure itself, it looks (unsurprisingly) like a Drupal "course" is what I'm after. As an actual example, I'm writing a course in the Git version control system, so I'll want to create a new "Git" course manual. At that point, I'll want to (as I read it) define the chapters, which would be child pages(?). Each chapter could theoretically consist of sections, which could themselves be defined as further child pages, and so on. And this part is important.
I'll eventually have a lot of little manual snippets of various topics lying around (pages?) and, at any time, I want to be able to define a new course manual just by creating a new "Course" and adding a bunch of child pages, with those child pages being shareable across multiple manuals. And a "page" (if that's the right terminology) that might represent a chapter in one manual might represent only a section of a chapter in another manual -- it would all depend on how I chose to create the hierarchical structure of that manual and which child pages were included.
And in the end, people could stop by my site and peruse the entire manual online, perhaps by following Prev/Next/Up links, or using a collapsible contents menu, whatever works. So that's the first part -- I just want to start creating new course manuals with an empty hierarchical structure and, little by little, start fleshing them out with child pages, and subchild pages, and pulling in other pages and so on. What's the best way to accomplish that? Each manual being a "Course"? It looks that way but I'm not totally sure.
The second part is just as important -- at any time, I want to press a button and have the entire manual sent to the printer, with appropriate formatting applied to it. Obviously, I'd like to define whatever transformations are appropriate to turn the online manual into "printable" form -- being able to specify page breaks, that sort of thing. So that's an independent problem, but it's still essential.
So ... thoughts? If someone has already gone down this road and is willing to share, that would be great. I hang out at Hub Ottawa a lot these days and if someone local to Ottawa has the time, I'm more than happy to pay for an hour or two of assistance to make sure this is done correctly.
Drop me a note at rpjday@crashcourse.ca if you want to chat further privately.
rday
Comments
My current layout for a couple online courses I wrote once ...
Just for additional entertainment value, if you go to my web site, http://crashcourse.ca (I'm truly not trying to advertise my skill set here, just want you to see what I did once), up in the top left, there are links to two kernel programming courses I wrote.
Apparently, each of them was created as a "Book", while individual course chapters were created as "Course"s. I have no idea what I was thinking at the time since, in hindsight, that really seems weird.
In any event, pointers to good advice appreciated.
Some ideas...
The first thing you may want to consider is getting your site to D7, as setting this type of a structure is going to take some effort and it would be a shame to have to re-do it in D7 a few months from now.
A lot of what you want to do can be accomplished with Books, however, there is one requirement which cannot - pages which are part of multiple books. So if that is a mandatory requirement then forget book module.
I think you can accomplish a lot of what you need using Entity Reference (D7) / Node Reference (D6). A book is really just pages which are linked with parent / child relationships - so a simple page with an ER field that references one or more nodes can also provide this and meet the requirement that a page/chapter can belong to one or more books.
Then for Table of Contents, Flattened printable view, Navigation, etc. you will just need to do some views. The TOC view is fairly simple, you just need to list nodes referenced by the page and potentially a php_field to call views_embed_view to get the children of each referenced page. You can do this recursively to show the entire TOC (all depths) but you might also consider limiting it to depth 3 for usability purposes.
Navigation will be a bit tricky, the back/next would require some thought, but I don't think it would be impossible. Back is a bit tricky with multiple parents. I might even consider an alternate navigation scheme entirely.
A couple other features of that could be useful are:
Entity Reference Prepopulate: This could be used for the Add Child link functionality on a page.
References Dialogue: Can be used to have nice modal windows to create/edit referenced nodes from within the parent node edit form.
Overall, I would be relying heavily on views and panels to make this construct work...Good-luck!
Thoughts on the above ...
I have no problem with moving my site to D7, but I'd definitely want to hire someone to help me with that.
Re: pages as part of multiple books, let me make sure I explain that clearly. For each new course I write, I want to create a new Course/Book/Whatever, and initialize it with the appropriate frontmatter. For each chapter, I'd want to write an individual child page(?), then just place it as a child under that Book, is that the way it's normally done. Each chapter -- a new page, a new adding as child page to Book.
In some cases, a chapter might be designed to consist of even further child pages representing subsections. And in a perfect world, I'd be able to cannibalize pages for multiple courses. It's not a deal-breaker, I could live without it, but it seems like it wouldn't be that hard. I really want to write arbitrary "modules" of content without even knowing what I'm going to do with them yet. So it sounds like Entity Reference(D7) might do this for me. (It would be sort of like XIncludes in XML, right?)
I will read further before addressing the rest but, as I've mentioned previously, I'm willing to pay someone to help me out here. I spend a fair bit of time at the Hub in downtown Ottawa and it would be ideal for me to meet with someone there, find a quiet corner, and spend a few hours doing all of this so I can see it happening and try to keep up.
More later ...
Some followup thoughts on the above
So what I've decided to do is start with a fresh Drupal 7 install on my Ubuntu laptop and start writing there, and I can always move the content to my website at my convenience, but there's still some confusion as to how to structure the books themselves.
Again, I want to define a number of courseware manuals -- let's call them "books" for now. For each new book I write, I want to start with a skeleton of the chapters, and I will almost certainly not write the content in order -- I'll jump around and add sections here and there depending on my interest.
The important thing is that I want to write individual content modules of some kind -- would those be "pages"? And I'll want to link those modules into one or more manuals whenever I want. And I want the freedom to have as many levels of linking as I want in any book.
It may be that a book will have some chapters, and those chapters will contain sections, and some of those sections might consist of subsections and so on -- I don't want any hard limit on the depth of that hierarchy. And the very bottom of any part of the hierarchy of a book will be the leaf nodes or, in my case, those individual content modules. And the very same module of content should be allowed to be a chapter in one book, a section in another book, a subsection in a third book, etc. No restrictions.
So as long as I know this can be done, I can start writing the individual modules/pages of content, and decide later how to start assembling them into a book. Is this what the Entity Reference module gives me? I'll worry about final aesthetics later, like depth of TOC and so on. For now, I just want to start entering content, knowing that, later, I can start building my books from it. So would those leaf content modules be Drupal "Book pages"? Thoughts?
Some thoughts
The basic structure of chapters and child pages is very straightforward using the Book module. It also gives you the ability to create a printer-friendly version of pages and child pages, so you can print a chapter or an entire book.
Re. specifying page breaks, ideally you want to set things up so the breaks happen automatically based on style (as opposed to doing it manually) and this you can do by configuring the CSS in your theme (http://www.javascriptkit.com/dhtmltutors/pagebreak.shtml)
The gnarly bit that you're looking for is the capability to do single-sourced content (having a chunk of content display in two or more places without actually duplicating the text).
A couple of years ago I was really pushing for this capability to be developed and implemented on drupal.org for use with the Drupal documentation. You can read a long discussion about it here (http://groups.drupal.org/node/52098). I stopped pushing for this when it became apparent that this wasn't going to happen on d.o in the near future, but several people have developed their own solutions to this problem. One option is this module (http://drupal.org/project/dita) which uses DITA, a widely used approach for single sourcing technical content. I haven't used the module myself, so I can't say how well it works but you might want to get in touch with Kristof Van Tomme (http://groups.drupal.org/user/1541) to see where he's at with the project.
Lee
Book vs ER
@LeeeHunter mentions book module which does exactly as described. The only problem is that you would would like to have chapters be part of multiple books. Perhaps, a decent solution would be as follows:
Set-up 3 content types:
- Book: has a multi-entity reference field (autocomplete) which references chapters
- Chapter: content-type which can be a book, use Book Helper module or something like it automatically create a book when this type of node is created.
- Book Page: Pages which can be part of a Chapter, again Book Helper or other modules are nice because you can set them up so that your 'Add child page' links create nodes of this type.
Now, you can use the neat features of the book module to assemble chapters which can be re-used in different books via ER. You can use Views to create your TOC and even your printer-freindly version. I would also use admin_views and enable the book administration VBO which provides enhanced book management features - I have recently modified it for another site to be able to list pages which were not part of a book and bulk add them using an action.
The nice thing about having the three different content-types is that you can have different fields available for Books (cover image), Chapters (abstract, topic taxonomy tags) and a standard Book Page (title, body).
Have you tried using the
Have you tried using the "Insert page break for printing" in TinyMCE?
Recipe
I've got a recipe for this sort of thing over at Setting up and displaying hierarchical data in Drupal 7.