Ordered collections of pages that aren't blog posts

[greghendershott]

It might be tempting to use Frog for an ordered collection of pages that aren't blog posts. Example applications:

• A presentation (instead of PPT)
• A series of instructional pages on a how-to web site.
• A little photo gallery whizzy-whatcha.

If you're tempted to try, it's a kludgy mess. Sure you could create each slide or page as a blog post. But to order them, you have to give them "dates" ... and in reverse order. Meh.

Also, you probably prefer to have just one .md source file for the whole series of pages. (I think this is certainly true for the presentation use-case, and probably true for the others.)

Non-post pages

• Create a .md (or .scrbl) file anywhere under _src.

• Although non-post pages don't have meta-data (a.k.a. front matter), now they optionally could:

  Title: title
  Date: date
  Multi-page:

  Note that Tags is N/A for non-postpages. The key is the Multi-page item, which means to process it into multiple pages. Let's say the file is foo.md.

  • It becomes one or more pages in a subdirectory of the file's base name, foo/. So, foo/1.html, foo/2.html, and so on. Better: Slug the title of each one. So, foo/slug-of-page-1-title.html, and so on.
  • Within the source file, some directive indicates a page break. Some ideas:
  • Level 1 headings. Benefits:
    • Fits an "outline" model.
    • Provides the title for each page.
  • An HTML comment such as <-- page -->. (precedent: <-- more -->).
  • The resulting pages have previous / next buttons to nave among them. Also an up button.
  • A foo.html is generated at the same level as foo.md. It's a little index file with TOC or whatever. Perhaps it's everything up to the first page directive. Details, details.

    Works with blog posts, too?

Although the original motivation was non-blog-post pages, I suppose that's orthogonal. Such a file could be a blog post (under _src/posts). The post page would be the index page with TOC and a little content. The prev/next at that top level would still be among other blog posts. The only difference from a single-page blog post is that most of the content would be spread among the sub-pages. Of course those sub-pages would prev/next among themselves.

In this case the Multi-page: flag would be an optional extension to the existing meta-data (Title, Date, Tags).

Scribble equity?

Scribble already knows how to create multiple HTML pages from a single .scrbl source. If a Multi: field is added to metadata for .md sources, probably we should try to honor that .scrbl sources, too. This would mean running Scribble once to get at the metadata, and (possibly) re-running it if a Multi field is found. But, so what.

[samth]

I think that http://pyret.org uses Frog in this fashion.

[greghendershott]

I think you're right about Pyret.

I also had a specific request for this kind of feature via email, which prompted me to create this issue.

I actually have a branch implementing this. But I'm leery of merging it unless/until there's enough demand for it.

Also: I already have in mind another design, for a "Frog2", that would be less-monolithic. I have someone using Frog with 600+ blog posts migrated from LiveJournal. I didn't design with that in mind. Frog handles that, but too slowly IMO. Instead it should use more of a compile / link / make model. I would definitely still want raco frog to be a simple/easy front-end, but it would act as a driver of other, smaller tools.

The reason I mention that, here, is that this kind of feature would probably fall out more cleanly from that new design. In fact it would probably be something people could just do for themselves, without it even being a "feature".