We launched new forums in March 2019—join us there. In a hurry for help with your website? Get Help Now!
    • 38850
    • 110 Posts
    I am mocking up a website that will allow book reading. The website functionally works more like a blog, where you open the "book", then have a table of contents for the sidebar instead of blog categories.

    The functionality of the website needs to be feature rich. They read one chapter at a time, and have previous and next buttons to go to the next chapters. Each chapter can be linked to, and sub-chapters therein. Individual chapters can have comments, as well as comments about the book as a whole.

    There can be files attached to chapters as well. And the whole book can be exported as a PDF, or individual chapters printed out directly.

    As you can see, I need to be able to do a lot of work with "chapters" almost as individual entities, like resources unto themselves.


    I thought about having one book as a resource container and then each chapter as a sub-resource.
    I thought about using the Collections addon to do something similar.

    Neither of these seem best from the perspective of making exports, and the author making sweeping changes to the book. In other words, they have to edit each chapter individually, and it's not easy to blend chapters or rewrite things, add chapters, and make other global type edits.
    Also I'm not sure how I could generate a PDF export via many resources. This is probably not the most difficult problem tho.
    And I'm not sure how I would handle chapters having subchapters. Another Collection or container on the sub-item?


    What I'd LIKE is that the main book is a single resource (perhaps they have lots of books?). Then a user loads this "page". Then through some magic, the chapters, links, comments, files and everything are dynamically parsed out from a master document that the author can edit as a whole without screwing up the front-end display.

    I know it's a tall order! But there are lots of features needed here, like analytics on a per-chapter basis. Link counts for sharing and social, etc.

    Due to the number of features I need to control, I don't believe a simple script to parse out a PDF or even a Markdown doc and generate some pagination will be good enough. The "pages" a user sees online are not arbitrary lengths, they will view an entire chapter, no matter how long it is, so I can't use generic paginators that split up pages by a static number of lines or words.

    This almost feels more like a wiki, but with tighter control over individual "books" and chapters and sub-sections, and hierarchy. It will track authors, showing books by author and so forth. Most popular books, most comments, other stats.

    I really don't know how I would organize this in the resource tree, but allow authors a way to edit their books and upload new versions on their own! This is not even covering the idea of doing revisions or handling source control! Like if an author "updates" their book every year, they might want to read past versions of the book, or do comparisons.

    Is this even a job for MODX? Is this where I should be looking at advanced book formats like MOBI or EPUB?

    Thanks for any ideas!
      • 44580
      • 189 Posts
      This almost feels more like a wiki
      I think you hit the nail on the head. You'd be short of what you want, but a lot closer than if you started from scratch in MODX. I have not tried to extend a wiki, but there is at least a framework to allow you to do so - for example: http://www.mediawiki.org/wiki/Manual:Extensions
        • 3749
        • 24,544 Posts
        That *is* a tall order. The thing that makes it almost impossible is the requirement that the author be able to edit the unified document.

        If that wasn't required, you could make each chapter a resource, and let the Author create and edit the chapters in NewsPublisher. The table of contents could then be done with Wayfinder.

        A custom snippet could aggregate the chapters and produce the PDF file, and I think Quip (or a modified version of it) could handle the comments.

        To let the author edit the unified book, I think you'd have to teach the author to insert tokens of some kind, then update the resources with a custom snippet that parsed the book file. It would be easy for things to become completely corrupted, though, if the author made a mistake in the formatting.
          Did I help you? Buy me a beer
          Get my Book: MODX:The Official Guide
          MODX info for everyone: http://bobsguides.com/modx.html
          My MODX Extras
          Bob's Guides is now hosted at A2 MODX Hosting
        • I wonder if you could do something like what I've done with cssSweet and RO.IDEs for my CSS management?

          I have a context for the stylesheet resources. This uses resources for blocks, or even single dirctives, of CSS, for example, one for the menu, one for the footer, etc. Then I have a chunk with a single getResources call, using the &includeContent property, with a simple tpl of "[[+content]]". This generates a single chunk with the contents of all of the CSS pages. In this case, I have a plugin that gets the chunk and writes all of that to a compressed .css file when one of these CSS resources is saved.

          The case of the book would be only slightly different. You would have contexts for each book, and have the various chapters and sub-chapters as the usual Tree structure. Your main site context (web) would have a resource for each book. On that resource would be the getResources snippet, specifying the context relevant to that book. A few details would need to be worked out, like chapter headings and such, but that would all be a matter of the getResources tpl. You would end up with one huge page, depending on how big the book is that might be an issue. I'm sure something could be worked out, like using getPage to provide pagination. As a single long page, there are plenty of ways to make it into a PDF file; browsers on the Mac can use the Print menu to save any page as PDF.

          The book editors would have access to their own context for editing, while readers would just get the one page from the main (web) context. [ed. note: sottwell last edited this post 9 years, 4 months ago.]
            Studying MODX in the desert - http://sottwell.com
            Tips and Tricks from the MODX Forums and Slack Channels - http://modxcookbook.com
            Join the Slack Community - http://modx.org
          • Hm. I think I just talked myself into a complete re-design of the MODX Cookbook. Thank you for the idea, vigilante!

            Actually pdoMenu might be a better choice of an aggregating snippet, since it has more field selection and resource selecting and filtering options than Wayfinder, and you need to get the resources in their proper chapter and sub-chapter order. You would use custom tpls to craft a flattened "nested list", so the chapters and their sub-chapters would be in the proper order.

            Another pdoMenu call would produce the table of contents. This could vary from a sidebar TOC using named anchors in the case of a full-page display, or just loading a page with the selected chapter. A template switcher plugin would be useful for handling a choice of single long page using pdoPage or not, or getting individual chapters on a page. Lots of potentiality here! [ed. note: sottwell last edited this post 9 years, 4 months ago.]
              Studying MODX in the desert - http://sottwell.com
              Tips and Tricks from the MODX Forums and Slack Channels - http://modxcookbook.com
              Join the Slack Community - http://modx.org
              • 38850
              • 110 Posts
              Quote from: sottwell at Dec 18, 2014, 07:54 AM
              Actually pdoMenu might be a better choice of an aggregating snippet, since it has more field selection and resource selecting and filtering options than Wayfinder, and you need to get the resources in their proper chapter and sub-chapter order. You would use custom tpls to craft a flattened "nested list", so the chapters and their sub-chapters would be in the proper order.

              I don't see an addon called pdoMenu in package management.

              Where you do guys find/search for addons not in package management?
                • 4172
                • 5,888 Posts
                its included in the pdoTools - package together with some other very usefull and fast snippets and reusable classes
                  -------------------------------

                  you can buy me a beer, if you like MIGX

                  http://webcmsolutions.de/migx.html

                  Thanks!
                  • 38850
                  • 110 Posts
                  I don't know guys. This seems like something that would be very hard to do no matter what CMS one uses.

                  I wouldn't use a context per book, I'm not sure this would scale well. Perhaps too much overhead for what a context is meant to be used for? Imagine hundreds of books or even thousands.

                  Even the thought of one resource per book gives me shivers. I don't know what the MODX tree looks like with hundreds or thousands of entries but I can't image it's easy to use at that point, or fast.

                  This leaves me with an organizational problem. One resource per author? One resource per alphabetical letter (A - Z + #)?
                  The resource itself would clearly have to be some kind of database tool to organize author/books/chapters/attachments/comments therein.

                  As far as authors being able to edit their book as a whole, or chapter by chapter, I don't know. A WIKI pattern would serve this purpose I guess. I haven't heard of any WIKI addons for MODX though, that would be a big project indeed!

                  On the other hand, if I forget about scale and if there were just 5 or 10 books to deal with, using resources alone would likely suffice.
                    • 44580
                    • 189 Posts
                    If it walks like a wiki and talks like a wiki...

                    I understand that in a MODX forum it would be nice to suggest a MODX solution, but your requirements list points to a wiki being the better tool for the job. Rather than look for a wiki extension for MODX, I'd be looking at how to extend a wiki to fill the fewer gaps.
                      • 38850
                      • 110 Posts
                      Quote from: gissirob at Dec 30, 2014, 12:34 AM
                      If it walks like a wiki and talks like a wiki...

                      I understand that in a MODX forum it would be nice to suggest a MODX solution, but your requirements list points to a wiki being the better tool for the job. Rather than look for a wiki extension for MODX, I'd be looking at how to extend a wiki to fill the fewer gaps.

                      I thought so as well. But WIKIs tend to be unstructured and do not function in a manner like "author -> Title -> Chapters". WIKIs that I've used are unstructured, without any built-in structure or context of hierarchy.

                      Without structure and hierarchy, a WIKI certainly doesn't walk like this duck.