home ~ projects ~ socials

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:

{
  "neopolitan": {
    "neo_keys": "neo_values"
  },
  "pages": {
    "neopolitan_id": {
      "blocks": []
    }
  }
}

The first pass from Neopoligen turns it into:

{
  "neopolitan": {
    "neo_keys": "neo_values"
  },
  "pages": {
    "neopoligen_id": {
      "blocks": [],
      "neopolitan_id": "original_id",
      "neopoliten_id": "internal copy of the id for easy access",
      "output_path": "relative_path/index.html",
      "url_path": "relative_path", 
    }
  }
}

The neopoligen_id is determied in this order:

  1. 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.
  2. 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 v index.html output is handled etc... (If there are multiple -- metadata blocks on the page, the last one with an -- path: attribute is used.
  3. 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.

{
  "site": {
    "block_tags": {
      "tag_name": [
        {
          "category": "string", 
          "kind": "string",
        }
      ]
    },
    "block_groups": {
    },
    "block_types": {

    },
    "page_groups": {
      "group_name_lc": [
        "page_id"
      ]
    },
    "page_tags": {
      "tag_name_lc": [
        "page_id"
      ]
    },
    "pages": {
      "neopoligen_id": {
        "blocks": []
      }
    }, 
    "page_ids_from_source_path": {
      "source_path": "page_id"
    },
    "page_ids_from_url": {
      "page_url": "page_id"
    },
    "page_urls_from_id": {
      "page_id": "url_path"
    },
    "page_short_titles": {
      "page_id": ["spans"]
    },
    "page_titles": {
      "page_id": ["spans"]
    },
    "site_urls": {
      "url": [
        {
          "from": "block|span", 
          "page_id": "string",
          "optional_title_or_text_from_span": ["spans"]
        }
      ]
    },
    "untitled_pages": ["page_id"],
    "wiki": {
      "term": "page_url"
    }
  }, 
  "page": {
    "blocks": [], 
    "neopoligen_id": "string",
    "neopolitan_id": "string",
    "output_path": "string", 
    "url_path": "string"
  }
}

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.

Introduction

-- end of line --