Allow / in work IDs (superworks)

[ewen-lbh]

This means, in scattered mode, searching for works with a .ortfo/ at arbitrary depth. Maybe limit (configurable) the search depth to like 5 ? (Who needs more than that for a portfolio anyway)

Use case: collections of works.

In that case, if a/b, a/c and a/d all have a .ortfo/ but a also has one, is a's .ortfo/ to be treated specially? => no reason, but it would be useful to allow for such a thing, turning those pages into super-work pages that link to sub-works

Although the actual implementation of such a thing is left to ortfo/mk, we could have a new field in the output database json that lists IDs of child works, sth. like

[
  {
    "id": "a/b",
    "subworks": []
  },
  {
    "id": "a/c",
    "subworks": []
  },
  {
    "id": "a/d",
    "subworks": []
  },
  {
    "id": "a",
    "subworks": ["b", "c", "d"]
  },

Although I guess that since IDs of children works are guaranteed to have slashes, this "children" property could be constructed from the resulting JSON quite easily (Python implementation here, but this is the gist of it):

import json

db = json.load(...)
def subworks_of(work_id):
    return (w['id'].replace('work_id/', '') for w in db if work_id in w['id'].split('/'))

(we could even use pathlib here I think)

[ewen-lbh]

Conflicts with ortfo/mk-old#48, but the conflict can be resolved easily: a/b, a/c and a/d would all have "a" in the "collections" field, and a itself would be a regular work. The "subworks" field would not be present

It is up to the portfolio template to determine that a work is a superwork, by searching for a work's ID in all the "collections" field of the works database, and eventually show a list of works contained in the collection after the work itself.

The "a" superwork would not be declared in collections.yaml, so no page for it would be generated by a template containing :collection in its path: the :work template would take care of the generation of its page.

Those superworks are works that describe collections of sub-works, and are different from a Work collection described by an entry in collections.yaml, since this superwork has all the metadata of a normal work (namely mediae, blocks, paragrahs, colors, etc.) whereas a Work collection basically just has a description and a "learn more" link. Thus they can't be handled like Work collections as described in ortfo/mk-old#48.