Most advanced CCK (Content Construction Kit) component for Joomla 1.5. Multi user, multi section/catalog, supports Joomfish, core SEF, own comments, rating, tags system, ...
Actually, this request has been mentioned by somebody else but I need to make it as focus.
Is it possible for Black Ice to have a book rather than a single article.
As comparison, you may check what drupal has.
With a book, you may have many chapters for a single title. Which is mean, what to be shown on frontpage is the book title list. And when we click the title, it will show the chapters and may be the sub chapters.
We will do NEXT and PREV records on article full view.
But regarding what you said, I thought very seriously. I know that solution is not Book native but we cannot change architecture of Black Ice to feet Book style. Then we get more problems with other section kinds.
But I think it will be possible to do with Black Ice. The only difference that Chapters will be Categories. And if chapter have text you can put it in category description.
We also already have Ajax MooTree category index. So you can open categories like book chapters. Like you do in in CHM files. We will also add option to show records in that tree. It means that if you unfold last category in category tree it will show category records.
With new markup template you will be able position this category index as right or left column. Something like on this drawing.
I agree with you. The book feature should not change the architecture of Black Ice but utilize the existing.
And I believe, the book feature can be achieved by manipulating the categories as you explained above. But, there are several things need to be considered:
1. A book is one entity with one title. It just like a single article. Which means, a user (who has author privilege) may create books as many as he want. So, there will be so many categories created by users. The questions is, can Black Ice handle it?
2. Regarding the submission interface. Since book is one entity, the submission interface shall be related for each articles under the book title. For example: When a user want to create an article, the Black Ice should show options: create single article or Book. If the Book is selected, then the Black Ice shall asked user to input the book title and may be text for the description. And user may save the Book. Next, once again user shall create article and select book. But this time, user has option to select to create new book or add article into existing book. If existing is selected, then user has to create a chapter and put text there. But user may add a nested chapters.
3. About the book view. When user select a book, then (as in your drawing), user will get chapters index. And on the page view, there is next - prev - up navigation.
4. About Book List. Let's say I have an online book reader website. Of course, I want show the list of my books collection with illustration of the cover on the front page. When a user add a new book, the list shall be updated.
5. Search and filters. There should be a book search and filters.
I think, those are the things required so we can call the feature as Book Feature. And you must have it in your solution.
ngarasan 1. A book is one entity with one title. It just like a single article. Which means, a user (who has author privilege) may create books as many as he want. So, there will be so many categories created by users. The questions is, can Black Ice handle it?
First idea that goes into my head is to create field, with will accept longHTML boot and then analyze it using H1, H2, ... titles, separate it into parts and show by parts with ajax navigation.
And all your rest just convince me that this is the right way to go.
I sure there are already some HTML book formats for book readers. We need to take one or to formats and implement it into one field. On book save it will pare and save by chapters, titles, ... and then we can show TOC, page navigation.
(1) I thought on this problem months ago, because I'm writing an online CAD for fictions writers, mixing Resources and many custom parts.
For me, a book is an entity of a different nature than its chapters.
So, books and chapters are in different sections.
I have a Book section (with its subcats) with its type,defining covert, 4th page, preface, dedicacy, style etc etc AND a relate- field pointing on another section, Texts and Peritexts. This later section has a very different type, among which 7 fields (number -special autoincrementing field, to keep good order in the Book-,Text -html field-, Epigraph -textArea field-, picture, relate- to the Book.)
This way, you are completely free for your structure, the access problem is no more a problem, and you avoid stupid things like give an ISBN number to chapters...
(2) As for articles, since I say to writers to stay focused on a single subject in a single article, they needed a mean to create clusters of articles to explore a subject in different manners. So, subarticles were the solution. I use relate child/parent to let users link the articles between them. Often, there is a head article that gives an index to its subarticles, but the structure doesn't need to be that hierarchic. Most of the time, they do it for articles with at least 4-5 subarticles. For small clusters of 2-5 articles, they are direcly linked and the linked list appears at bottom of each article. The important thing is that authors are free of their choice (from single isolated articles to clusters). Explanations are quite useless, test showed me it's immediately understood by writers, which is mandatory in terms of usability.
With relate child/parent and/or relate fields, that's easy to build, and, more important, easy to understand by authors.
(3) MEResource gives us the way to build graphs between entities and it's the way to make it properly. Anyway, I think that we should never never never mix entities of a different nature in the same sections. Doing so gives problems, is tricky to make it work properly, is poorly maintainable, is a call to laziness for the designer ("I put everything in the same bag so I don't ask questions about the graph relationship between the entities. What entities, anyway, huhhh?") masking problems that will arise later and worse of worse is not user friendly.
The fact that Drupal does it is irrelevant. They are freemen and have the right to be wrong. As us.
Thanks for the sharing. And love to hear that someone has thought about it as well.
I was thinking to use relate child/parent and tried it a bit but then, I gave up. Well I have to say that I am not skillful web designer/programmer. But I always believe that it should be possible to have it using ME Resources.
So, I just hoping that ME Team will make it easier for some unskillful like me.
My simple idea was, string up several articles using any relation field. The title of the book is the main article, the chapters/content is the sub articles. Well, I have the idea already but lack of capability made me fail.
So here I am.
Asking ME team to help me.
I am quite sure that no need to change Resource Core. May be it just need one or two additional field which is I don't have capability to build it.
Jacques Thank you for your current experience. It is really useful
jacques Anyway, I think that we should never never never mix entities of a different nature in the same sections
That used to be our recommendation. But not for Black Ice. I think that it will be no matter for lack Ice what type to display even in one list. It will automatically inter-alias similar fields.
ngarasan So, I just hoping that ME Team will make it easier for some unskillful like me.
Yes we will. What is now in my head is.
There are 2 kind of books.
1. Section as one book. Usefull if you create public manual or some product documentation. When users contribute to this book and add new and new pages.
Solution for this to add features
Article navigation with titles.
Links to records in category index on category module.
Special "Read ALso" field that allow to chose articles when you create article. For example you created page "How to ... part 1". Then you create page "How to ... Part 2" and during creation chose "How to ... part 1" as read also article. Then no matter what article you read, at the bottom you will see list of articles you also have to/may read.
2. Book as single article. It is applicable when 1 writer want to submit few books. And many books are in the same section.
Solution for this
Special field that allow upload book in one of populas format like DJVU or EPUB or something else. This field will unpack book and store in it's own format. With means of Ajax show book content in article full view.
If I want to build an online reading website with 2 type of user (writer and reader) and the writer may write many books, which solution shall I choose?
There will be many writer there thus, there will be many books. And I consider the possibility for mobile version as well, so the format shall be as light as possible.
And of course, the website is a community site so I will need the Touch Extension (which has no code name yet ).
I believe ME Team has thought a good solution for the Book. But please let me share my idea (but of course from unskilled perspective).
CASE:
Let's say I am an administrator of online reading website. I have many Writers and Readers. One of my writer want to write a Book named "World of Animal" and will save it in Animal Category. The book consist of 3 chapters named:
Chapter Mamalia
Chapter Reptilia
Chapter Insect
And Chapter Reptilia will consist of:
Sub Chapter Komodo
Sub Chapter Dinosourus
So, The book structure will be: Book: World of Animal
Chapter Mamalia
Chapter Reptilia
Sub Chapter Komodo
Sub Chapter Dinosourus
Chapter Insect
PREPARATION:
What will I do as the Administrator is: 1) Create a Type named: Book.
In this type, I will put some field:
a) Special Select Field (this field is not yet available). This is special field which acts like a select simple but has control over the next Field. With this field, a user will have to select between options we set. Let's say we put "Book" and "Content" options. If the user select the first option (Book), then the next (b), (c), (d) and (e) Fields will be enabled and has to be filled. And if the user select the second option (Content), the (b) and (f) Fields will be enabled and has to be filled.
b) Book Contruction Field (this field is not yet available). This Field is the key of Book Feature. This is a combobox consist of 2 items: "Main Book" and "Related Item". If the Writer want to create a book for the first time, then the Writer shall select "Main Book". With this selection, the title of the article will be the "Book Title" and this selection will be useful for index.
And if the Writer want to write a content of the book, the Writer shall select "Related Item". The selection of this item ("Related Item") will show list of "Book Title" created and the Writer must select one of them. Selecting the "Book Title", will show list of "Contents" under the "Book Title". If NO "Content" available yet, then no need to select and finish.
If there are "Contents" available then, the Writer select one of the "Contents", and 2 options will be shown. They are: "Related Item is Same Level" or "Related Item is Upper Level". Selecting "Related Item is Same Level" will make the new article is on the same level as related. And selecting "Related Item is Upper Level" will make the new article is the sub level of the related article. And finish.
c) Image Field (for the cover)
d) Text Field (for description)
e) Text Field (for Book Code or ISBN or etc )
f) HTML Field
2) Assign the Type to a section.
END USER PROCESS:
After the Type has been prepared and section ready, now my Writer can write his book.
Below is the step of my Writer writing a Book.
1) Create a Book. After my Writer select the "Book" Type, he has to choose "Book" on "Special Select Field". With this selection, the Writer has to fill in:
Title (will be the Book Title) --> "World of Animal"
Book Contruction Field --> Select "Main Book"
Image Field (for the cover) --> Insert Image
Text Field (for description) --> Fill the description
Text Field (for Book Code or ISBN or etc ) --> Fill the code.
Save the article!
2. Create Chapter Mamalia. After my Writer select the "Book" Type, he has to choose "Content" on "Special Select Field". With this selection, the Writer has to fill in:
Title (will be the Chapter Title) --> "Mamalia"
Book Contruction Field --> Select "Related Item" --> Select Book Title: "World of Animal" (no content available yet).
HTML Field --> write the content of the chapter.
Save the article.
3. Create Chapter Reptilia After my Writer select the "Book" Type, he has to choose "Content" on "Special Select Field". With this selection, the Writer has to fill in:
Title (will be the Chapter Title) --> "Reptilia"
Book Contruction Field --> Select "Related Item" --> Select Book Title: "World of Animal" --> Select content: "Mamalia" --> Choose "Related Item is Same Level".
HTML Field --> write the content of the chapter.
Save the article.
4. Create Sub Chapter Komodo After my Writer select the "Book" Type, he has to choose "Content" on "Special Select Field". With this selection, the Writer has to fill in:
Title (will be the Chapter Title) --> "Komodo"
Book Contruction Field --> Select "Related Item" --> Select Book Title: "World of Animal" --> Select content: "Reptilia" --> Choose "Related Item is Upper Level".
HTML Field --> write the content of the chapter.
Save the article.
5. Create Sub Chapter Dinosourus After my Writer select the "Book" Type, he has to choose "Content" on "Special Select Field". With this selection, the Writer has to fill in:
Title (will be the Chapter Title) --> "Dinosourus"
Book Contruction Field --> Select "Related Item" --> Select Book Title: "World of Animal" --> Select content: "Komodo" --> Choose "Related Item is Same Level".
HTML Field --> write the content of the chapter.
Save the article.
6. Create Chapter Insect After my Writer select the "Book" Type, he has to choose "Content" on "Special Select Field". With this selection, the Writer has to fill in:
Title (will be the Chapter Title) --> "Insect"
Book Contruction Field --> Select "Related Item" --> Select Book Title: "World of Animal" --> Select content: "Reptilia" --> Choose "Related Item is Same Level".
HTML Field --> write the content of the chapter.
Save the article.
And DONE. Book is finish.
THE APPEARANCE:
And what will happend if my Reader open "Animal Category"? They will see list of books:
World of Animal
Wild Animals
The Predators
And when my Reader select the "World of Animal", he will see a cover, description, book code and TOC.
And then, when my Reader open the "Chapter Reptilia", they will see:
Almost anything you want can be accomplished by Resources standard features, IMHO. Why so much special and "hardcoded" stuff? The needed terms and application is interchangable. Readers display is also a matter of versatile modules and templates. The only thing that is missing in Resources is: Creating additional Root/SubCategories by users (The current v1.5 user-categories are a bit different in display and usage... "Jaques" already wrote about it in another topic)
I think that there is no need for sub chapters as separate articles. I mean article as chapter it is OK and sub chapters are simply headers and paragraphs. After all it is book, reading, and nothing wrong to load all chapter at once.
Although your explanation created idea of 3d book type.
1) You create article type book in section books. It has description, cover, TOC, ... 2) Pages are added as "Add New" option of relation field. Actually something like "Add New Page or Chapter".
I mean chapters to be children of parent type book.
I think all 3 methods will be possible
Section as book
Book field
Related articles Book/Pages
But it will be very complicated to create multilevel chapter books in any method. Not very much for first method though. I think that levels of book chapters should be limited to 1. I mean it may looks like this
Chapter 1
Chapter 2
Sub chapter 1
Sub chapter 2
Chapter 3
But in this case, Chapter 1, 2, 3 are articles, and sub chapter 1, 2 is a <h3> headers.
I mean that we may analyze HTML and create correct chapter/sub chapter (TOC) structure but anyway there should be only one level articles.
Technically, let's say we have book field with is HTML but in the list it shows analyzed HTML structure. Then when user created a book, then added 2 related articles chapters, when user see article he sees something like this.
Where Green is a list of related articles sorted by time ascending. Chapter 1 and 2 are titles of children chapters and sub chapters are what book field shows in the list like link to article with anchor by this header.
Cool! It fulfill my expectation. (And I love Gandalf there - I mean the picture of man with hat and smoking pipe :D You will know what I mean if you read Lord of the Rings). But I still have 2 questions: 1. How will the submission page look like? 2. How will the article or chapter full page look like (I mean when I click any chapters links)?
ngarasan 2. How will the article or chapter full page look like
Something like this
This is article view. Bottom red is a standard page navigation.
Sherlock Holmes is a parent field.
Of course using custom templates you can place/position those differently. Also using our Read Also field possible to place small TOC after/before each chapter with list of other chapters.
If user user digits in chapter names (1. The begining, 2. The continue, etc...) he may sort them by title.
... 
Comments
But regarding what you said, I thought very seriously. I know that solution is not Book native but we cannot change architecture of Black Ice to feet Book style. Then we get more problems with other section kinds.
But I think it will be possible to do with Black Ice. The only difference that Chapters will be Categories. And if chapter have text you can put it in category description.
We also already have Ajax MooTree category index. So you can open categories like book chapters. Like you do in in CHM files. We will also add option to show records in that tree. It means that if you unfold last category in category tree it will show category records.
With new markup template you will be able position this category index as right or left column. Something like on this drawing.
I agree with you. The book feature should not change the architecture of Black Ice but utilize the existing.
And I believe, the book feature can be achieved by manipulating the categories as you explained above. But, there are several things need to be considered:
1. A book is one entity with one title. It just like a single article. Which means, a user (who has author privilege) may create books as many as he want. So, there will be so many categories created by users. The questions is, can Black Ice handle it?
2. Regarding the submission interface. Since book is one entity, the submission interface shall be related for each articles under the book title.
For example: When a user want to create an article, the Black Ice should show options: create single article or Book.
If the Book is selected, then the Black Ice shall asked user to input the book title and may be text for the description. And user may save the Book.
Next, once again user shall create article and select book. But this time, user has option to select to create new book or add article into existing book. If existing is selected, then user has to create a chapter and put text there. But user may add a nested chapters.
3. About the book view. When user select a book, then (as in your drawing), user will get chapters index. And on the page view, there is next - prev - up navigation.
4. About Book List. Let's say I have an online book reader website. Of course, I want show the list of my books collection with illustration of the cover on the front page. When a user add a new book, the list shall be updated.
5. Search and filters. There should be a book search and filters.
I think, those are the things required so we can call the feature as Book Feature. And you must have it in your solution.
And all your rest just convince me that this is the right way to go.
I sure there are already some HTML book formats for book readers. We need to take one or to formats and implement it into one field. On book save it will pare and save by chapters, titles, ... and then we can show TOC, page navigation.
Book cove may be simple image field.
I thought on this problem months ago, because I'm writing an online CAD for fictions writers, mixing Resources and many custom parts.
For me, a book is an entity of a different nature than its chapters.
So, books and chapters are in different sections.
I have a Book section (with its subcats) with its type,defining covert, 4th page, preface, dedicacy, style etc etc AND a relate- field pointing on another section, Texts and Peritexts.
This later section has a very different type, among which 7 fields (number -special autoincrementing field, to keep good order in the Book-,Text -html field-, Epigraph -textArea field-, picture, relate- to the Book.)
This way, you are completely free for your structure, the access problem is no more a problem, and you avoid stupid things like give an ISBN number to chapters...
(2)
As for articles, since I say to writers to stay focused on a single subject in a single article, they needed a mean to create clusters of articles to explore a subject in different manners. So, subarticles were the solution.
I use relate child/parent to let users link the articles between them. Often, there is a head article that gives an index to its subarticles, but the structure doesn't need to be that hierarchic.
Most of the time, they do it for articles with at least 4-5 subarticles. For small clusters of 2-5 articles, they are direcly linked and the linked list appears at bottom of each article.
The important thing is that authors are free of their choice (from single isolated articles to clusters). Explanations are quite useless, test showed me it's immediately understood by writers, which is mandatory in terms of usability.
With relate child/parent and/or relate fields, that's easy to build, and, more important, easy to understand by authors.
(3) MEResource gives us the way to build graphs between entities and it's the way to make it properly. Anyway, I think that we should never never never mix entities of a different nature in the same sections.
Doing so gives problems, is tricky to make it work properly, is poorly maintainable, is a call to laziness for the designer ("I put everything in the same bag so I don't ask questions about the graph relationship between the entities. What entities, anyway, huhhh?") masking problems that will arise later and worse of worse is not user friendly.
The fact that Drupal does it is irrelevant. They are freemen and have the right to be wrong. As us.
Jacques
Thanks for the sharing. And love to hear that someone has thought about it as well.
I was thinking to use relate child/parent and tried it a bit but then, I gave up. Well I have to say that I am not skillful web designer/programmer. But I always believe that it should be possible to have it using ME Resources.
So, I just hoping that ME Team will make it easier for some unskillful like me.
My simple idea was, string up several articles using any relation field. The title of the book is the main article, the chapters/content is the sub articles. Well, I have the idea already but lack of capability made me fail.
So here I am.
Asking ME team to help me.
I am quite sure that no need to change Resource Core. May be it just need one or two additional field which is I don't have capability to build it.
regards
ngarasan
Thank you for your current experience. It is really useful
That used to be our recommendation. But not for Black Ice. I think that it will be no matter for lack Ice what type to display even in one list. It will automatically inter-alias similar fields.
Yes we will. What is now in my head is.
There are 2 kind of books.
1. Section as one book.
Usefull if you create public manual or some product documentation. When users contribute to this book and add new and new pages.
Solution for this to add features
2. Book as single article. It is applicable when 1 writer want to submit few books. And many books are in the same section.
Solution for this
- Special field that allow upload book in one of populas format like DJVU or EPUB or something else. This field will unpack book and store in it's own format. With means of Ajax show book content in article full view.
What do you think?If I want to build an online reading website with 2 type of user (writer and reader) and the writer may write many books, which solution shall I choose?
There will be many writer there thus, there will be many books.
And I consider the possibility for mobile version as well, so the format shall be as light as possible.
And of course, the website is a community site so I will need the Touch Extension (which has no code name yet ).
Do you have any idea for the solution?
I believe ME Team has thought a good solution for the Book.
But please let me share my idea (but of course from unskilled perspective).
CASE:
Let's say I am an administrator of online reading website. I have many Writers and Readers.
One of my writer want to write a Book named "World of Animal" and will save it in Animal Category.
The book consist of 3 chapters named:
- Chapter Mamalia
- Chapter Reptilia
- Chapter Insect
And Chapter Reptilia will consist of:- Sub Chapter Komodo
- Sub Chapter Dinosourus
So, The book structure will be:Book: World of Animal
- Chapter Mamalia
- Chapter Reptilia
- Sub Chapter Komodo
- Sub Chapter Dinosourus
- Chapter Insect
PREPARATION:What will I do as the Administrator is:
1) Create a Type named: Book.
In this type, I will put some field:
a) Special Select Field (this field is not yet available).
This is special field which acts like a select simple but has control over the next Field.
With this field, a user will have to select between options we set. Let's say we put "Book" and "Content" options.
If the user select the first option (Book), then the next (b), (c), (d) and (e) Fields will be enabled and has to be filled.
And if the user select the second option (Content), the (b) and (f) Fields will be enabled and has to be filled.
b) Book Contruction Field (this field is not yet available).
This Field is the key of Book Feature. This is a combobox consist of 2 items: "Main Book" and "Related Item".
If the Writer want to create a book for the first time, then the Writer shall select "Main Book". With this selection, the title of the article will be the "Book Title" and this selection will be useful for index.
And if the Writer want to write a content of the book, the Writer shall select "Related Item". The selection of this item ("Related Item") will show list of "Book Title" created and the Writer must select one of them.
Selecting the "Book Title", will show list of "Contents" under the "Book Title". If NO "Content" available yet, then no need to select and finish.
If there are "Contents" available then, the Writer select one of the "Contents", and 2 options will be shown. They are: "Related Item is Same Level" or "Related Item is Upper Level".
Selecting "Related Item is Same Level" will make the new article is on the same level as related. And selecting "Related Item is Upper Level" will make the new article is the sub level of the related article. And finish.
c) Image Field (for the cover)
d) Text Field (for description)
e) Text Field (for Book Code or ISBN or etc )
f) HTML Field
2) Assign the Type to a section.
END USER PROCESS:
After the Type has been prepared and section ready, now my Writer can write his book.
Below is the step of my Writer writing a Book.
1) Create a Book.
After my Writer select the "Book" Type, he has to choose "Book" on "Special Select Field". With this selection, the Writer has to fill in:
- Title (will be the Book Title) --> "World of Animal"
- Book Contruction Field --> Select "Main Book"
- Image Field (for the cover) --> Insert Image
- Text Field (for description) --> Fill the description
- Text Field (for Book Code or ISBN or etc ) --> Fill the code.
Save the article!2. Create Chapter Mamalia.
After my Writer select the "Book" Type, he has to choose "Content" on "Special Select Field". With this selection, the Writer has to fill in:
- Title (will be the Chapter Title) --> "Mamalia"
- Book Contruction Field --> Select "Related Item" --> Select Book Title: "World of Animal" (no content available yet).
- HTML Field --> write the content of the chapter.
Save the article.3. Create Chapter Reptilia
After my Writer select the "Book" Type, he has to choose "Content" on "Special Select Field". With this selection, the Writer has to fill in:
- Title (will be the Chapter Title) --> "Reptilia"
- Book Contruction Field --> Select "Related Item" --> Select Book Title: "World of Animal" --> Select content: "Mamalia" --> Choose "Related Item is Same Level".
- HTML Field --> write the content of the chapter.
Save the article.4. Create Sub Chapter Komodo
After my Writer select the "Book" Type, he has to choose "Content" on "Special Select Field". With this selection, the Writer has to fill in:
- Title (will be the Chapter Title) --> "Komodo"
- Book Contruction Field --> Select "Related Item" --> Select Book Title: "World of Animal" --> Select content: "Reptilia" --> Choose "Related Item is Upper Level".
- HTML Field --> write the content of the chapter.
Save the article.5. Create Sub Chapter Dinosourus
After my Writer select the "Book" Type, he has to choose "Content" on "Special Select Field". With this selection, the Writer has to fill in:
- Title (will be the Chapter Title) --> "Dinosourus"
- Book Contruction Field --> Select "Related Item" --> Select Book Title: "World of Animal" --> Select content: "Komodo" --> Choose "Related Item is Same Level".
- HTML Field --> write the content of the chapter.
Save the article.6. Create Chapter Insect
After my Writer select the "Book" Type, he has to choose "Content" on "Special Select Field". With this selection, the Writer has to fill in:
- Title (will be the Chapter Title) --> "Insect"
- Book Contruction Field --> Select "Related Item" --> Select Book Title: "World of Animal" --> Select content: "Reptilia" --> Choose "Related Item is Same Level".
- HTML Field --> write the content of the chapter.
Save the article.And DONE. Book is finish.
THE APPEARANCE:
And what will happend if my Reader open "Animal Category"?
They will see list of books:
- World of Animal
- Wild Animals
- The Predators
And when my Reader select the "World of Animal", he will see a cover, description, book code and TOC.And then, when my Reader open the "Chapter Reptilia", they will see:
- Title: Reptilia
- Content: bla bla bla.
- Sub Chapters:
- Other Chapters:
That's all.+ Komodo
+ Dinosourus
+ Mamalia
+ Insect
I think that there is no need for sub chapters as separate articles. I mean article as chapter it is OK and sub chapters are simply headers and paragraphs. After all it is book, reading, and nothing wrong to load all chapter at once.
Although your explanation created idea of 3d book type.
1) You create article type book in section books. It has description, cover, TOC, ...
2) Pages are added as "Add New" option of relation field. Actually something like "Add New Page or Chapter".
I mean chapters to be children of parent type book.
I think all 3 methods will be possible
- Section as book
- Book field
- Related articles Book/Pages
But it will be very complicated to create multilevel chapter books in any method. Not very much for first method though. I think that levels of book chapters should be limited to 1. I mean it may looks like this- Chapter 1
- Chapter 2
- Sub chapter 1
- Sub chapter 2
- Chapter 3
But in this case, Chapter 1, 2, 3 are articles, and sub chapter 1, 2 is a <h3> headers.I mean that we may analyze HTML and create correct chapter/sub chapter (TOC) structure but anyway there should be only one level articles.
Technically, let's say we have book field with is HTML but in the list it shows analyzed HTML structure. Then when user created a book, then added 2 related articles chapters, when user see article he sees something like this.
Where Green is a list of related articles sorted by time ascending. Chapter 1 and 2 are titles of children chapters and sub chapters are what book field shows in the list like link to article with anchor by this header.
What do you think?
Something like this
This is article view. Bottom red is a standard page navigation.
Sherlock Holmes is a parent field.
Of course using custom templates you can place/position those differently. Also using our Read Also field possible to place small TOC after/before each chapter with list of other chapters.
If user user digits in chapter names (1. The begining, 2. The continue, etc...) he may sort them by title.
Really look great.. Can't wait to try it!
Thank you ME Team..