Generate a per-directory `index.html`

[OndraZizka]

I was looking for some automated way to list pages, but not the way posts are listed (chronologically), but hierarchically: Each directory would have an index.html that would list the documents automatically.

I havent found a way to do it without changing the Java code, so I suggest to add this feature. I imagine it this way:

JBake knows the documents and their metadata in each directory.
Let's add a template, e.g directoryIndex.ftl, and this would be called for each directory, with the model containing data of the items in that directory: documents, static files and subdirectories.

This way, users could create a hierarchical set of pages: Documentations, catalogs, photo albums, taxonomies, ... without linking all of it manually and editing an index each time they add/remove/change some item.

Further, this template could include files from that directory, so it could add a per-directory header (or other page part).

Lastly, the data supplied to the template could be adjusted with a config file in that directory. For instance,

• filter.documents.tags = tag1 && !tag2 could filter which documents would be in the model,
• filter.directories.name = !.* && !*.backup could omit some dirs from the model. etc.
  This could work well with what's described in #490 Allow per-dir config overrides.

What do you think about this feature? Personally, for me this is probably the top-wanted.

Edit: Someone wanted the same in jbake-user group.

[OndraZizka]

One alternative approach would be:

1. Generate a JSON file containing a tree with an index of all documents, following the directory structure.
2. JBake could render the same dirIndex.ftl to each directory
3. This page would download the JSON and render whatever it likes with JavaScript.

But perhaps it wouldn't be much easier than to implement it as described at the top.
(BTW the JSON could be useful for other uses, too.)

[jonbullock]

This is something I've wanted to add for a while.

Linking relate issues #165, #436 and #19.

[OndraZizka]

I am starting working on it, but going to a vacation so it will take a while.

I have a strong temptation to refactor everything on the go, but it seems it would make merging a very long process, right? So I will stick to ODocument and lists of sets of maps of lists :)

[lprimak]

bump