mirror of
https://github.com/BookStackApp/BookStack.git
synced 2026-02-05 00:29:48 +03:00
Proposal: Sections #1748
Reference in New Issue
Block a user
Delete Branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Originally created by @sburkett on GitHub (May 28, 2020).
Describe the feature you'd like
I've been reading feature requests for things like "sub-chapters" and the like. This concept is similar, but involves a layer above shelves.
Carrying forward the library metaphor used in Bookstack ... libraries do have shelves of books, but those shelves are arranged in "sections". Otherwise, it would take you forever to find what you were looking for.
For a more realistic Bookstack-centric example, we currently have something like the following (with one shelf expanded a little here):
The books, of course, have chapters and pages in them. Now, the "Ansible Implementation" book (along with a lot of others) really should fall under some sort of "System Administration" category (currently would be a "shelf"). However, I don't want to have more than one shelf related to technology - I just want one shelf to rule them all.
What I'd like to be able to do, is something like this:
Benefits of the Feature
These are probably somewhat obvious, but:
Additional context
Currently, the app uses separate models/tables for
bookshelves,books,chapters, andpages. Obviously, the easiest thing to do would be to add another model forSectionthat would parent shelves. However, a more robust approach would be to use the most excellent calebporzio/parental package to have a baseBookstackContainerclass (or whatever you wanted to call it), which could easily be extended by other classes (even user-defined ones) to provide whatever level of organization the user wanted.Just a thought :)
@sburkett commented on GitHub (May 28, 2020):
After reviewing the code base, it would appear that adding a "Section" layer would be by far the easiest thing to do. Making it definable would require a complete overhaul of the application as quite a bit of functionality is tightly coupled with each of the existing layers.
@sburkett commented on GitHub (May 29, 2020):
I've been thinking about this a bit more. I've forked off the current master and soon may take on the effort I've described in the Additional Context section above. Would love anyone interested in having that capability react with a thumbs up or what not.
@ssddanbrown commented on GitHub (May 29, 2020):
Hi @sburkett,
Thank you for the detailed thought-out suggestion.
Personally I'd prefer not to support another level in the hierarchy. My comment from 2016 here still represents how I'd feel about this; If anything I'm probably more strongly against this now than in 2016 since we now have shelves.
@sburkett commented on GitHub (May 29, 2020):
Sure, no problem. I do feel that a completely configurable hierarchy with a set of defaults of what is there now (shelf->book->etc) is the ideal scenario for everyone, though. No doubt it is a tremendous undertaking, since it almost becomes a rewrite, but I might take it on just for kicks lol. We'll see. Life will most assuredly get in the way!