Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Previously, Collections were the only way of listing pages, which is required for building index pages. Looking after the source code after a while made me realize that I really value simplicity, and Collections were too much logic in a single mechanism, especially for simple use cases.
The question raised in #12 is pertinent: it shouldn't be that complicated to list pages, so these changes add a function that allows listing pages with a simple filter and sort option.
How it works
Griffin works in two stages: parsing, where files are read and split into a
{frontmatter, content}
pair, and rendering, which is when files are written to the output directory. This logic has been extended a bit to also store the path the file comes from relative to the root directory, so that it is searchable.The frontmatter/metadata is really all that's needed for listing pages, so we're now storing the parsed file metadata in ETS.
In the rendering stage, we now inject a
@list_pages
assign as a function wrappingGriffinSSG.list_pages/3
which enables listing pages from layouts.