Neopoligen 2.0 Features
The Next Stage
Data Updates
Basic structure idea:
Neopolitan returns pages that use the filepath (relative to the content root) as their ID key. Neopolitan updates this ID to be either the relative URL or a custom ID from a -- metadata
-- id:
attribute.
The original data that comes from Neopolitan looks like this:
The first pass from Neopoligen turns it into:
The neopoligen_id
is determied in this order:
-
If there's a
-- metadata
block on the page with an-- id:
attribute in it, that ID gets pulled as a text string (i.e. not tag or shorthand processing) and used for the ID. (If there are multiple-- metadata
blocks on the page, the last one with an-- id:
attribute is used. -
If there's a
-- metadata
block on the page with an-- path:
attribute in it, the path gets used. TKTKTK: details on chomping the/
characters, how directory output vindex.html
output is handled etc... (If there are multiple-- metadata
blocks on the page, the last one with an-- path:
attribute is used. - The relative path to the output directory is used.
TODO: In all cases, leading and trailing /
should be optional and handled if they are there or not. Gotta make sure the /
of the home page is handled appropriately.
The key goal is to make sure the IDs can be used for things like tlink
to auto link to pages.
Updated Page AST
This is what the AST looks like after the Neopoligen upgrades.
Wiki Functionality
the wiki tag in content
a -- wiki-ref:
attribute on pages
and have as many as you want.
a top level neo-wiki
object is added next to pages
in the site object that has the mappings so they are easier to get to without having to loop through all the pages every time to find them.
auto populate wiki tags for plurals and 's
and maybe other stuff.
the check for wiki tags is done by making everything lower case so case doesn't matter.
Three Types Of Dates
Created, Completed, Updated.
Previous Next Functionality
Set up for next/previous _in_folder
and next_folder/previous folder
and parent folder
and child folders
these are all based off source paths
should there be a list of folders? what would it link to? if there was a _toc file in it? that feels like maybe a bridge too far.
Book Table Of Contents
Set up directory structure for use withe tables of contents. that create them with links and titles for the sites.
Show how -- short-title:
attributes could be used?
Maybe make those part of the standard.
Images and Image Gallery Folders
Page Groups
Like tags, but more refined with the idea that they're independent of tags.
Page Tags
General tags.
Block Groups
Like Page Groups but for blocks.
Thinking this would be a collection of page ids (not url_paths) with the block index numbers for the corresponding blocks that match the group
Block Tags
Like page tags, but for blocks.
Thinking this would be a collection of page ids (not url_paths) with the block index numbers for the corresponding blocks that match the tag. Actually, it should be an object that has the url_path as well as the block indexes. So you can link as well as look up via ID.
Block Types
List of all block types with page id keys for objects that have the page_urls and block indexes.
Block types have their metadata associated with them.
Page metadata is added as well.
Auto footnote numbering
Any text ids can be used to map the content to the footnote nodes.
Automatic Figure Numbering
Could it be set up so that there's a counter on the page and then you reference it by something like [@ figure @]neoj
or [@ figure - 1 @]
to get to previous ones (or + #
for following ones.
Most Recently Changed Page
A URL where you can always see the most recently changed page so you can just leave it open and it shows whatever you're currently working on. This would be in the .neopoligen
directory.
Theme Stuff
Q: Should CSS and support files be in the theme with all the templates? Feels like maybe so it's a single drag and drop to put stuff in place.
Q: Should there be an override directory for blocks/spans or should you just edit the files in the theme directory themselves. I feel like the later is easier to get your head around. You don't have to start out with having to remember which of multiple spots something is.
Page IDs From Neopoligen
The page IDs that come from Neopoligen are the relative paths to the source files from the document root. It's up to the engines to handle turning them into links, etc...
For Neopoligen: the engine makes a determination of where the file should be output based either on the source file location or an -- id:
attribute in the -- metadata
block for the page (and the last -- metadata
block if there's more than one).
Two keys are added to the page ast: the full url to the .html file, and the relative urls to use to get to it (e.g. if an ID is used that doesn't end in .html
the output goes to an path - index.html file in directory named with the id. This is done so that the files can be served by pointing to the directory which makes it easier to move off of Neopoligen to another system that doesn't use .html
extensions.