Generate pages from an array of data

[0x00cl]

I'm trying to archive cards CCG, these cards have different editions and for each edition I have a .yaml file. Each edition can contain 100+ cards, and so in each .yaml file I have a big list of cards with name, description, costs and other data exclusive to that card.
I want each card to have its own page where it displays all of its information. eg. http://localhost/gen1edition/{{ card.name }}.

I'm trying to avoid having hundreds of .md files with the same variable names set between "---" and just manage the cards data from one big file (.yaml).

Jekyll doesn't do this natively but someone created a 3rd-party plugin for it. jekyll-datapage_gen

If the data is an array, it is straightforward to build an index page, containing all records, using a Liquid loop. In some occasions, however, you also want to generate one page per record. Consider, e.g., a list of team members, for which you want to generate an individual page for each member.

So for example if I have this yaml file

- name: bob
  hair_colour: black
- name: alice
  hair_colour: white
- name: John
  hair_colour: brown

It should be able to generate 3 pages based on the name for example at http://localhost/members/bob, http://localhost/members/alice and http://localhost/members/john.

And the layout used to display this, should be able to access data for each person, so in this case hair_colour can be used to display it in their page.

[epage]

(sorry for the delay)

My concern with this is how well we can design a system that is "good enough" for the most people rather than only really works for one person's use case. Jekyll has the advantage of a plugin system though I've been considering a plugin system for cobalt. So far I was only considering Liquid plugins. This would be a page-generating plugin (I wonder if this could be re-used for custom pagination). It could generate data for a page that maps to what an md file contains. The source would be the problem. We don't want to dump all of cobalts state into a Lua compatible data type; that'd be slow and prevent parallelism. There is also different kinds of state, site.data like in this case or the pages of a collection in the pagination case (though, if needed, these can be separate solutions).

If we focus on just this, the plugin could

• have a function giving the key into site that it expects to contain an array
• have a function we call per array item where we convert to Lua types and then get back everything we need after converting back to Rust
  We then just look in the plugins folder, load it, ask it what it wants to run on, and then call it.

In the short term, a quick hack would be to have a quick and dirty script that

• Deletes a fixed directory and recreates it
• Creates placeholder .md files
  Yes, it has the hundreds of md files problem but it at least is manageable until cobalt supports this use case.