removed old docsys design and test files

This commit is contained in:
Jonathan Shook
2020-04-19 05:55:03 -05:00
parent f877ff6af3
commit 4a88200b3f
40 changed files with 0 additions and 939 deletions

View File

@@ -1,52 +0,0 @@
body {
font-size: 1.0rem;
font-family: -apple-system, BlinkMacSystemFont, "Segoe UI", "Roboto", "Oxygen", "Ubuntu", "Cantarell", "Fira Sans", "Droid Sans", "Helvetica Neue", sans-serif;
}
h1 {
background-color: lightblue;
}
a.toc-link {
text-decoration: none;
}
/*h1::before, h2::before, h3::before, h4::before, h5::before, h6::before {*/
/* display: block;*/
/* content: " ";*/
/* height: 60px;*/
/* margin-top: -60px;*/
/* visibility: hidden;*/
/*}*/
h2 {
display: block;
font-size: 1.5em;
margin-block-start: 0.83em;
margin-block-end: 0.83em;
margin-inline-start: 0px;
margin-inline-end: 0px;
font-weight: bold;
}
@media screen and (min-width: 30em) and (max-width: 60em) {
.w-20-0-m {
width: 0;
}
}
@media screen and (min-width: 60em) {
.w-25-l {
width: 25%;
}
}
/*ol {*/
/* display: block;*/
/* list-style-type: decimal;*/
/* margin-block-start: 1em;*/
/* margin-block-end: 1em;*/
/* margin-inline-start: 0px;*/
/* margin-inline-end: 0px;*/
/* padding-inline-start: 40px;*/
/*}*/

View File

@@ -1,60 +0,0 @@
.toc {
overflow-y: auto
}
.toc > .toc-list {
overflow: hidden;
position: relative
}
.toc > .toc-list li {
list-style: none
}
.toc-list {
margin: 0;
padding-left: 10px
}
a.toc-link {
color: currentColor;
height: 100%
}
a.toc-link {
text-decoration: none;
}
.is-collapsible {
max-height: 1000px;
overflow: hidden;
transition: all 300ms ease-in-out
}
.is-collapsed {
max-height: 0
}
.is-position-fixed {
position: fixed !important;
top: 0
}
.is-active-link {
font-weight: 700
}
.toc-link::before {
background-color: #EEE;
content: ' ';
display: inline-block;
height: inherit;
left: 0;
margin-top: -1px;
position: absolute;
width: 2px
}
.is-active-link::before {
background-color: #54BC4B
}

View File

@@ -1,54 +0,0 @@
<html>
<head>
<title>Doc System</title>
<link rel="stylesheet" href="/docsys-styles.css">
<link rel="stylesheet" href="/docsys-tocbot.css">
<link rel="stylesheet" href="https://unpkg.com/tachyons@4.10.0/css/tachyons.min.css"/>
<!--
<link href="https://fonts.gstatic.com" rel="preconnect" crossorigin>
<link rel="stylesheet" href="https://fonts.googleapis.com/css?family=Roboto:300,400,400i,700|Roboto+Mono&display=fallback">
<style>body,input{font-family:"Roboto","Helvetica Neue",Helvetica,Arial,sans-serif}code,kbd,pre{font-family:"Roboto Mono","Courier New",Courier,monospace}</style>
-->
</head>
<body class="dark-gray lh-copy">
<div class="fl w-20 pv4"> <!-- left menu -->
<nav class="toc is-position-fixed toc-left js-toc relative z-1 absolute overflow-hidden">
<OL class="toc-list">
{{# topics.headers }}
<LI class="toc-list-item">
<a href="{{path}}.html#{{id}}" class="toc-link node-name--H3">{{name}}</a>
<OL class="toc-list is-collapsable">
{{# subTopics }}
<LI class="toc-list-item">
<a href="{{path}}.html#{{id}}" class="toc-link node-name--H5">{{name}}</a>
</LI>
{{/ subTopics }}
</OL>
</LI>
{{/ topics.headers }}
</OL>
</nav>
</div>
<div id="main" class="content fl w-60 pv4"><main>{{{ inner.rendered }}}</main></div>
<div class="w-20 pa4 fr"><nav class="toc is-position-fixed fr" id="doc-toc"></nav><!-- right menu -->
</div>
<script src="/tocbot.min.js"></script>
<script>
tocbot.init({
// Where to render the table of contents.
tocSelector: '#doc-toc',
// Where to grab the headings to build the table of contents.
contentSelector: '#main',
// Which headings to grab inside of the contentSelector element.
headingSelector: 'h1, h2, h3',
});
</script>
</body>
</html>

View File

@@ -1,18 +0,0 @@
# Virtdata Docs Design
This directory contains the design docs for the doc system to be used
with Virtdata and downstream projects. This will be called *DocSys* from here forward.
A list of topics is on the left.
The view you are looking at now is rendered by DocSys from a template named
`index._md`. Here is how this view was rendered:
1. The webserver asked for a file named index.html.
2. This file didn't exist, but the DocSys FS layer knew it could be rendered from a source file named index.md, so it looked for one.
3. This file didn't exist, but the DocSys FS layer knew it could be rendered from a source file named index._md, so it looked for one.
4. index.md was rendered as a mustache template from index._md, using a view model which provided all the necessary details from the target URL.
5. index.html was rendered from index.md.
Thus, a chain of rendering occurred: [index._md](index._md) `->` [index.md](index.md) `->` [index.html](index.html). All of these files are viewable.

View File

@@ -1,37 +0,0 @@
# Templating
This doc system comes pre-wired to work with both
markdown and mustache as rendering layers. That means
that you can use either markdown or mustache to edit
or template content.
- [Mustache Docs](https://mustache.github.io/mustache.5.html)
- [JMustache Docs](https://github.com/samskivert/jmustache)
- [JMustache API](http://samskivert.github.io/jmustache/apidocs/)
However, the mustache templates render markdown by default.
If the need arises to template html directly from mustache,
then this will be added at that time.
## Examples
### paths as markdown
```
{{ paths }}
{{# paths }}
{{.}}
{{/ paths }}
```
### target as markdown
```
{{ target }}
```
### paths as html
{{ paths }}

View File

@@ -1,92 +0,0 @@
# Template Paths
Because the templating system is quite flexible, it can also mean
some clutter in the file system for new users. It may not be clear what
each type of file patter is for. This document should clarify that
both for new users and for implementors.
## file._extension
Any file which contains an extension with an underscore at the start is
considered a template file. Only these files will be evaluated dynamically
with mustache.
### Local Templates
Any file with a base name of `_._extension` is considered a local template. That is, any other file with the same extension will be wrapped within this template.
For example. A directory with files named
- `_._extension`
- `foo._extension`
will result in a virtual file `foo.extension` being visible on the file system. When this file is accessed,
the contents of `foo._extension` will be rendered into a
buffer, and then the contents of `_._extension` will be evaluated, using the result and view model of `_._extension`. The result will be cached as the content
of `foo.extension`
Local templates also wrap any file of the same extension.
That means that if a file named `bar.extension` were also in the directory, that accessing it would invoke the same
wrapping logic above.
Local templates only apply to files in the same directory
as the template.
### Hierarchic Templates
Hierarchic templates apply to files within subdirectories that
match the template extension. They are named `__._extension`.
For example, with the structure:
- dir1
- `__._extension`
- dir2
- dir3
- foobarbaz.extension
Accessing file `dir1/dir2/dir3/foobarbaz.extension` would cause
the template wrapping logic to apply with the contents of
`foobarbaz.extension` and `__._extension`. These layers of content
would be wrapped together like this:
- `/dir1/__._extension`
- `/dir1/dir2/di43/foobarbaz.extension`
## Layering
These templating mechanisms work together. For example, consider this directory structure:
- dir1
- `__._DOG`
- dir2
- `__._DOG`
- `_._DOG`
- dir3
- `_._DOG`
- `CAT._DOG`
Access to the file `/dir1/dir2/dir3/CAT.DOG` would
result in template nesting of
1. `/dir1/__._DOG`
2. `/dir1/dir2__._DOG`
2. `/dir1/dir2/dir3/_._DOG`
3. `/dir1/dir2/dir3/CAT._DOG`
Notice that `/dir1/dir2/_._DOG` is not included, while `/dir1/dir2/__._DOG` _is_.
## Logical and Physical Views
Since users may not want to see all the template
scaffolding needed to create a rich view, yet they
might want topical views of content, there are two
different ways of looking at the file system.
The logical view is the one which only shows the files
which are meant to be user-facing. This is provided
by default in the view model. These views do _not_ include files which are templates.
They physical view of the filesystem can be useful for
troubleshooting and debugging. These view are exposed
within the view model as **fs** elements.

View File

@@ -1,147 +0,0 @@
## Templating Design
- Static files which use standard extensions should be loadable without
triggering any render logic. This is important to make static content
load efficiently, such as themes, javascript libraries, etc.
- Markdown sections should be editable inside html templates. This is important to allow markdown users to contribute fluidly to the docs without requiring logs of HTML micro-management.
- Markdown should be able to make use of templating. This is important to
provide an intermediate and simple structural format that can be used
to drive high level changes in templates.
- Target files should be able to be wrapped automatically with a template
that is provided by their current directory.
_ Target files should be able to be wrapped automatically with a template
that is provided by the parent directory of the current directory.
- Rendering stages which are completed should be cached in memory,
as long as the underlying templates and data have not changed.
## Template File Names
All files which are intended to be interpreted as a template must have an
extension which starts with an underscore. For examples, both `myfile._md` and `myfile._html` would both be considered templates subject to
further processing. This convention is enforced by configuration of the
rendering layers, so that the user can be presented with a logical view
of content which does not include all the template level elements.
### Sources and Targets
All files which can be templated must have a specific source and target
template extension.
Take for example, an html template file foobarbaz:
The _source extension_ is `._html`. The file `foobarbaz._html` is the _source template_.
The _target extension_ is `.html`. The file `foobarbaz.html`
is the _target file_.
The mapping from the _source extension_ to the _target extension_ is the
key to configuring rendering layers. Each rendering layer is configured
with this mapping along with a renderer which can transform file content
from the _source template_ form to the _target file_ content.
### Renderer Configuration
The configuration described above is known as as an `extension mapping`. An extension mapping is meaningless without a way to transform the template into a file, thus a proper rendering configuration consists of the following:
- A source extension.
- A target extension.
- A renderer which can create a virtual file from a template.
If you have multiple extension mappings which chain together, such as `._md -> .md (mustache)` and `.md -> .html (markdown)`, then these will
cascade together gracefully.
## Rendering Steps
Normally, users do not access the template files directly. Ideally, users
are not even aware that there is templating happening at all.
These steps are followed when a user accesses a target file:
1. If the logical name exists on the physical file system, it is provided as-is. This means that for templating to work, the corresponding target file for a given source template must not physically exist on the file system.
2. if the target file does not exist, but a template file for it does, then:
1. If the file has already been rendered and the source modification time hasn't changed, the the cached copy is provided.
2. Otherwise, the target file is rendered to a _rendered file_, cached in memory, and also returned to the caller as a virtual file.
## Rendering Context
If the results of a template were always the same, then the templates would serve no special purpose. When a template is used to render a file, it needs some data to plug in to the template sections.
This data is provided in every case by a basic lazily constructed object model. This is called the TargetPathView. This is called the _source context_ for any rendered file.
The TargetPathView provides access to a few types of data:
- The target path itself.
- Breadcrumbs from the target path up to the filesystem root. (this is the internal virtual file system, and logically limited to the configured paths.)
- Semantic models of the target path, such as contained topics and categories.
- Support for internal rendering helpers, like rendering markdown inside html templates.
The combination of a specific rendering context and template is called
a _rendering scope_, thus a rendering scope has a version which is
the newest version of either components.
## Compositing
Composite templates are templates which can automatically layer together
in order to impose a format around target file rendering.
When two templates are composited together, they are set in a parent-child
relationship. As with templates, the context objects for these templates
are also set in a parent-child relationship.
This is the arrangement of a set of composite scopes in chain form:
```
+-------+ parent of -> +-------+ parent of -> +-------+
| tmpl1 | | tmpl2 | | tmpl3 |
+-------+ +-------+ +-------+
| view1 | | view2 | | view3 |
+-------+ <- child of +-------+ <- child of +-------+
```
In this arrangement, tmpl1 is the parent template of templ2, which is the parent of tmpl3. The rendering contexts have the identical arrangement.
When a parent template needs to access the direct child context, it does
so by using the name `inner`
#### Local Directory Template
If you have a template in a directory which has a base name of `_` (underscore) with the same extension as an active source template, then the source template will automatically be promoted to a composite template before it is rendered.
For example, if you have two files in a directory: `foobarbaz._md` and `_._md`, then the latter file becomes a template that wraps the former.
The contents of the `_._.md` template will wrap **any** other `*._md` template in this directory.
Within the local directory template, the context object is set to a TargetPathView as usual, but an additional element is present which provides access ot the target file under the name `target`.
Within the `foobarbaz._md` template, everything works as it usually does,
only its placement within the local directory template is determined by
the use of the `target` value.
## Hierarchic Wrapping
Moving from the target file up through the file system, if there are any
templates with the name `__._.md`, then these template are applied just
as above, but they apply for all elements, and they are applied recursively.
Taking the local directory template above into consideration with the
parent directory template, it is possible to have both apply. ...
## Directory Wrapping
As with any system which can have internal references, it is possible
to create a cyclic dependency. For example, as directory template
which provides a topic list must read the contents of all files which
it will be composited with. This creates a cyclic reference.
Presently, this is not supported. It is conceptually possible to
make a compositor which can read metadata like topics from rendered
partials without invoking the canonical name of the current target
in rendering, but this will be an incremental improvement.

View File

@@ -1,207 +0,0 @@
body {
background-color: #FFF
}
.transition--300 {
transition: all 300ms ease-in-out
}
.toc {
height: 100%;
width: 280px;
transform: translateX(0)
}
.content {
position: relative
}
.content h1:first-child, .content h2:first-child {
padding-top: 0;
margin-top: 0
}
.title {
font-size: 3em
}
.content {
margin-bottom: 95vh
}
.content ul, .content ol {
list-style: inherit
}
.content a {
color: #0977c3;
text-decoration: none;
border-bottom: 1px solid #EEE;
transition: all 300ms ease
}
.content a.no-decoration {
border-bottom: 0
}
.content a:hover {
border-bottom: 1px solid #0977c3
}
.content a:hover.no-decoration {
border-bottom: 0
}
a.toc-link {
text-decoration: none
}
.try-it-container {
transform: translateY(84%)
}
.try-it-container.is-open {
transform: translateY(0%)
}
.page-content {
display: block !important
}
.hljs {
display: block;
background: white;
padding: 0.5em;
color: #333333;
overflow-x: auto
}
.hljs-comment, .hljs-meta {
color: #969896
}
.hljs-string, .hljs-variable, .hljs-template-variable, .hljs-strong, .hljs-emphasis, .hljs-quote {
color: #df5000
}
.hljs-keyword, .hljs-selector-tag, .hljs-type {
color: #a71d5d
}
.hljs-literal, .hljs-symbol, .hljs-bullet, .hljs-attribute {
color: #0086b3
}
.hljs-section, .hljs-name {
color: #63a35c
}
.hljs-tag {
color: #333333
}
.hljs-title, .hljs-attr, .hljs-selector-id, .hljs-selector-class, .hljs-selector-attr, .hljs-selector-pseudo {
color: #795da3
}
.hljs-addition {
color: #55a532;
background-color: #eaffea
}
.hljs-deletion {
color: #bd2c00;
background-color: #ffecec
}
.hljs-link {
text-decoration: underline
}
.toc-icon {
position: fixed;
top: 0;
right: 0
}
#toc:checked ~ .toc {
box-shadow: 0 0 5px #c8c8c8;
transform: translateX(0)
}
.toc {
background-color: rgba(255, 255, 255, 0.9);
transform: translateX(-100%)
}
.toc.toc-right {
transform: translateX(100%);
right: 0
}
@media (min-width: 52em) {
.toc {
transform: translateX(0)
}
.toc.toc-right {
transform: translateX(0);
right: calc((100% - 48rem - 4rem) / 2)
}
.toc-icon {
display: none
}
.try-it-container {
display: block
}
.content {
margin-left: 280px
}
.toc-right ~ .content {
margin-left: 0;
margin-right: 280px
}
}
* {
box-sizing: border-box
}
body {
font-size: 1.2rem;
font-family: -apple-system, BlinkMacSystemFont, "Segoe UI", "Roboto", "Oxygen", "Ubuntu", "Cantarell", "Fira Sans", "Droid Sans", "Helvetica Neue", sans-serif
}
h1, h2, h3, h4, h5, h6 {
padding-top: 0.5em
}
h1:focus, h2:focus, h3:focus, h4:focus, h5:focus, h6:focus {
outline: 0
}
p {
margin-top: 0.25rem
}
pre {
display: block;
background: #f7f7f7;
border-radius: 2px;
border: 1px solid #e0e0e0;
padding: 2px;
line-height: 1.2;
margin-bottom: 10px;
overflow: auto;
white-space: pre-wrap
}
code {
display: inline;
font-size: .8em;
max-width: 100%
}

View File

@@ -1,16 +0,0 @@
<html>
<head>
<title>Virtdata Docs Design</title>
</head>
<body>
<h1>topics list</h1>
<UL>
{{# topics }}
<LI>{{name}}</LI>
{{/ topics }}
</UL>
</body>
</html>

View File

@@ -1,7 +0,0 @@
# Parent Template Example
{{# inner }}
- inner.rendered {{ rendered }}
- target: {{ target }}
- path: {{ path }}
{{/ inner }}

View File

@@ -1,3 +0,0 @@
# example header
Example paragraph

View File

@@ -1,3 +0,0 @@
{{# fs.paths }}
- [{{.}}]({{.}})
{{/ fs.paths }}

View File

@@ -1,21 +0,0 @@
# Local Directory Example
```
included render starts here
```
{{ inner.rendered }}
```
included render stops here
```
```
included template of inner object starts here
```
{{# inner }}
- target: {{ target }}
- path: {{ path }}
- version: {{ version }}
{{/ inner }}
```
included template of inner object stops here
```

View File

@@ -1,3 +0,0 @@
# example header
Example paragraph

View File

@@ -1,3 +0,0 @@
{{# paths }}
- '{{ . }}'
{{/ paths }}

View File

@@ -1,12 +0,0 @@
{{# markdown }}
# markdown rendered as html in markdown file
This is an example of markdown rendering.
Since this is a markdown processor inside a markdown file,
the result will be HTML, which the downstream markdown processing
should skip over.
{{/ markdown }}
# markdown as markdown in markdown file.
This is the normal markdown outside of the markdown processor.
It should be processed as markdown.

View File

@@ -1,8 +0,0 @@
<html>
<head>Example Mustache Rendering directly to HTML</head>
<body>
<p>
<span>The target is '{{ target }}'</span>
</p>
</body>
</html>

View File

@@ -1,19 +0,0 @@
{
'version': {{ version }},
'target': '{{ path.toString}}',
'paths' : [
{{# paths }}
'{{ . }}'{{^-last}},{{/-last}}
{{/ paths }}
],
'breadcrumbs' : [
{{# breadcrumbs }}
'{{ . }}'{{^-last}},{{/-last}}
{{/ breadcrumbs }}
],
'topics' : {
{ {# topics.list } }
'{ { name } }': '{ { path } }'{ {^-last} },{ {/-last} }
{ {/ topics.list } }
}
}

View File

@@ -1,6 +0,0 @@
<HTML>
<HEAD>Heading Test</HEAD>
<BODY>
{{{ inner.rendered }}}
</BODY>
</HTML>

View File

@@ -1,19 +0,0 @@
{
'version': {{ version }},
'target': '{{ path.toString}}',
'paths' : [
{{# paths }}
'{{ . }}'{{^-last}},{{/-last}}
{{/ paths }}
],
'breadcrumbs' : [
{{# breadcrumbs }}
'{{ . }}'{{^-last}},{{/-last}}
{{/ breadcrumbs }}
],
'topics' : {
{{# topics.list }}
'{{ name }}': '{{ path }}'{{^-last}},{{/-last}}
{{/ topics.list }}
}
}

View File

@@ -1,12 +0,0 @@
# Topics as list
{{# topics.list }}
- name: {{ name }}
- path: {{ path }}
- level: {{ level }}
{{/ topics.list }}
# Topics as Headers
# Topics as Files

View File

@@ -1,24 +0,0 @@
<html>
<head>Hierchical Wrapping Demo</head>
<body>
<h2>Begin Hierarchic Wrapping Layer</h2>
<div style="display: flex;">
<div style="width: 200px;">
<h3>topic list</h3>
<ul>
{{# topics }}
<li>{{ name }}</li>
{{/ topics }}
</ul>
</div>
<div style="display: inline;">
{{{ inner.rendered }}}
</div>
</div>
</body>
</html>

View File

@@ -1 +0,0 @@
<em>{{{ inner.rendered }}}</em>

View File

@@ -1,6 +0,0 @@
#### Topic 1
This is some content of topic 1.
It is nested within directory `category`.
It will *not* be rendered as a layered rendering, since it is not marked as a template file.

View File

@@ -1,6 +0,0 @@
#### Topic 2
This is some content of topic 2.
It is nested within directory `category`.
It *will* be rendered as a layered rendering, since it *is* marked as a markdown template file with the extension `._md`.

View File

@@ -1,11 +0,0 @@
## Begin Hierarchic Wrapping Layer
```
inner.rendered follows
```
{{ inner.rendered }}
```
End Hierarchic Wrapping Layer
```

View File

@@ -1,15 +0,0 @@
### begin local wrapping layer
```
inner.rendered follows
```
{{ inner.rendered }}
```
inner.rendered ends
```
### end local wrapping layer

View File

@@ -1,6 +0,0 @@
#### Topic 1
This is some content of topic 1.
It is nested within directory `category`.
It will *not* be rendered as a layered rendering, since it is not marked as a template file.

View File

@@ -1,6 +0,0 @@
#### Topic 2
This is some content of topic 2.
It is nested within directory `category`.
It *will* be rendered as a layered rendering, since it *is* marked as a markdown template file with the extension `._md`.

View File

@@ -1,19 +0,0 @@
{
'version': {{ version }},
'target': '{{ path.toString}}',
'paths' : [
{{# paths }}
'{{ . }}'{{^-last}},{{/-last}}
{{/ paths }}
],
'breadcrumbs' : [
{{# breadcrumbs }}
'{{ . }}'{{^-last}},{{/-last}}
{{/ breadcrumbs }}
],
'topics' : {
{{# topics }}
'{{ name }}': '{{ path }}'{{^-last}},{{/-last}}
{{/ topics }}
}
}

View File

@@ -1,12 +0,0 @@
<!DOCTYPE html>
<html lang="">
<head>
<meta charset="utf-8">
<meta name="viewport" content="width=device-width, initial-scale=1.0">
<title>server access example</title>
<style> body {padding: 0; margin: 0;} </style>
<script src="serveraccess.js"></script>
</head>
<body>
</body>
</html>

View File

@@ -1,8 +0,0 @@
const Http = new XMLHttpRequest();
const url = 'http://localhost:12345/status.json';
Http.open("GET", url);
Http.send();
Http.onreadystatechange=(e)=>{
console.log(Http.responseText);
}

File diff suppressed because one or more lines are too long

View File

@@ -1,9 +0,0 @@
+++
title: Example Title (TOML)
+++
# Header1
A Synopsis
## Header2ile

View File

@@ -1,9 +0,0 @@
---
title: Example Title (YAML)
---
# Header1
A Synopsis
## Header2

View File

@@ -1,3 +0,0 @@
bindings:
n: Identity();
name: NumberNameToString();