Open greghendershott opened 10 years ago
I think that http://pyret.org uses Frog in this fashion.
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".
It might be tempting to use Frog for an ordered collection of pages that aren't blog posts. Example applications:
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
.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:
Note that
Tags
is N/A for non-postpages. The key is theMulti-page
item, which means to process it into multiple pages. Let's say the file isfoo.md
.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.<-- page -->
. (precedent:<-- more -->
).foo.html
is generated at the same level asfoo.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 aMulti:
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 aMulti
field is found. But, so what.