mirror of
https://github.com/nosqlbench/nosqlbench.git
synced 2025-02-25 18:55:28 -06:00
cleanup old docs
This commit is contained in:
Jonathan Shook
15
docsys/docs/inspirations.md
Normal file
15
docsys/docs/inspirations.md
Normal file
@@ -0,0 +1,15 @@
|
||||
# Virtual DocSys
|
||||
|
||||
## Inspiring Examples
|
||||
|
||||
These are doc sites that have examples of good docs.
|
||||
|
||||
- [Apache Groovy](http://groovy-lang.org/documentation.html)
|
||||
- [Prometheus](https://prometheus.io/docs/prometheus/latest/querying/basics/)
|
||||
- [NetData](https://docs.netdata.cloud/)
|
||||
- [Optimizely](https://developers.optimizely.com/x/solutions/javascript/reference/index.html)
|
||||
- [Elastic Step by Step](https://www.elastic.co/guide/en/elasticsearch/client/java-rest/current/java-rest-high-search.html)
|
||||
- [Javascript.info](https://javascript.info/strict-mode)
|
||||
- [TiKV docs - explore the tabs](https://tikv.org/docs/3.0/concepts/overview/)
|
||||
- [rocket](https://rocket.rs/v0.4/overview/)
|
||||
|
||||
@@ -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;*/
|
||||
/*}*/
|
||||
@@ -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
|
||||
}
|
||||
@@ -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>
|
||||
|
||||
@@ -1,77 +0,0 @@
|
||||
# Virtual DocSys
|
||||
|
||||
## Inspiring Examples
|
||||
|
||||
These are doc sites that have examples of good docs.
|
||||
|
||||
- [Apache Groovy](http://groovy-lang.org/documentation.html)
|
||||
- [Prometheus](https://prometheus.io/docs/prometheus/latest/querying/basics/)
|
||||
- [NetData](https://docs.netdata.cloud/)
|
||||
- [Optimizely](https://developers.optimizely.com/x/solutions/javascript/reference/index.html)
|
||||
- [Elastic Step by Step](https://www.elastic.co/guide/en/elasticsearch/client/java-rest/current/java-rest-high-search.html)
|
||||
- [Javascript.info](https://javascript.info/strict-mode)
|
||||
- [TiKV docs - explore the tabs](https://tikv.org/docs/3.0/concepts/overview/)
|
||||
- [rocket](https://rocket.rs/v0.4/overview/)
|
||||
|
||||
## Architecture
|
||||
|
||||
The RealSimpleDoc system is meant to be embedded within
|
||||
other projects. It has been design to require a minimum of
|
||||
additional programming at the web layer, while allowing the tool
|
||||
builder to focus on direct content transforms of file types.
|
||||
|
||||
It is also designed to allow multiple projects to contribute
|
||||
documentation from their constituent components, with
|
||||
the contents being layered and composited dynamically.
|
||||
|
||||
Thus, the primary interface to the web server is provided as a filesystem
|
||||
instance that presents the directory structure and file content as
|
||||
the designer would want the user to see it, including content from
|
||||
multiple contributing components. This shifts the classic problem
|
||||
of doing server-side web programming in-depth for basic content
|
||||
authoring to one of simply having the right transformers in place.
|
||||
|
||||
## MetaFS
|
||||
|
||||
The content provided to the web server from the filesystem is provided
|
||||
by a set of filesystem modules that are collectively called MetaFS. This
|
||||
consists of three specific filesystems which each serve a simple purpose:
|
||||
|
||||
### VirtualFS
|
||||
|
||||
The VirtualFS filesystem type is simply a way to provide a view to a
|
||||
filesystem that is rooted at some directory path in a host filesystem.
|
||||
For example, a VirtFS that is created with a host filesystem path of
|
||||
`/usr/local/branson` will contain a Path entry for `/` which will look
|
||||
and behave like a root directory, but all contents accessed via this
|
||||
path will come directly from the host's filesystem `/usr/local/branson`.
|
||||
|
||||
### LayerFS
|
||||
|
||||
This filesystem type implements the ability to combine multiple filesystems
|
||||
in a layered fashion. Any attempt to access a file or directory in this
|
||||
filesystem will cause an internal request to the filesystems that have
|
||||
been added. LayerFS follows a couple basic rules when answering a request:
|
||||
|
||||
1. For calls that access attributes, the first response that
|
||||
contains attributes for a file that does exist will be used.
|
||||
2. When opening a file for write, the first filesystem which
|
||||
is writable will be used to open the file.
|
||||
3. Any requests which ask whether a file is readable or writable
|
||||
will have their answers filtered to match the effective best case.
|
||||
|
||||
### RenderFS
|
||||
|
||||
The RenderFS filesystem takes a set of transformers that are associated with a
|
||||
source and target file extension. The rules observed by this filesystem are:
|
||||
|
||||
1. For directory listings, if there is a file with one of the source extensions,
|
||||
but the target file for that basename does not exist, then the directory listing
|
||||
is modified to show both.
|
||||
2. For file attribute views, if a call fails internally to find file attributes,
|
||||
and a source version of the base name exist for that extension, then a virtual
|
||||
attribute view is created that has all the same attributes as the base name, but
|
||||
with a different file name.
|
||||
3. If there is attempt to read file contents which are of a known target extension,
|
||||
where the source file exists, the content will be rendered from the source file
|
||||
and returned.
|
||||
@@ -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.
|
||||
|
||||
@@ -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 }}
|
||||
|
||||
|
||||
|
||||
@@ -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.
|
||||
|
||||
@@ -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.
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
@@ -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%
|
||||
}
|
||||
@@ -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>
|
||||
|
||||
@@ -1,92 +0,0 @@
|
||||
# Topics in Files
|
||||
|
||||
Since DocSys is meant to make it easy to add docs to a system
|
||||
without doing much extra management, the ability to label and find
|
||||
topics of interest must be built in.
|
||||
|
||||
That means that topics will be mostly provided by convention, where
|
||||
the primary content simply _has_ a topic due to it's proper labeling.
|
||||
With Markdown being the primary format for most or all of the primary
|
||||
documentation, topics will be taken from specific places:
|
||||
|
||||
1. The directory structure containing the markdown files.
|
||||
2. The files containing the markdown.
|
||||
3. The headings within the markdown.
|
||||
|
||||
## Topic Structure
|
||||
|
||||
Of the three sources of information above, different facets of topics
|
||||
are represented. Anything under a given directory name will automatically
|
||||
be assigned to a category of that directory name. Further, if a directory
|
||||
has a markdown file with the right content, it may specifically set
|
||||
the category name. This is a future feature that will likely be called
|
||||
_markdown annotations_ in DocSys. For now, the directory name itself is
|
||||
simply used as a category name.
|
||||
|
||||
Each markdown file has a filename, but we aren't worried about that. The file
|
||||
name itself is not significant to the content, and can be used to organize
|
||||
the ordering of files in directory. For example, it is suitable to call
|
||||
a markdown file `00_somecontent.md` since we aren't paying attention to the
|
||||
file name. However, the file should have a canonical topic associated with it,
|
||||
for when you want to find files that speak to specific topics as a whole.
|
||||
These topics are called `File Topic`s, and are automatically given the topic
|
||||
name of the first heading in the file.
|
||||
|
||||
## Headings as Topics
|
||||
|
||||
Within a markdown file, the level of heading determines how topics are nested together.
|
||||
Any heading that is at a deeper level than the one that came immediately before it
|
||||
is considered a sub-topic of that heading.
|
||||
|
||||
## Views of Topics
|
||||
|
||||
There are multiple ways to view the topics in the content provided:
|
||||
|
||||
### Topic List
|
||||
|
||||
As a list of topics, irrespective of the source and structure. In this form,
|
||||
all the topics are presented as a flat list. This is suitable for indexing
|
||||
topics, for example.
|
||||
|
||||
### File Topics
|
||||
|
||||
As a list of file topics. This view of topics provides all the topic names
|
||||
that appear first for each file. This is suitable for finding or browsing
|
||||
a set of round topics which are each round and cohesive within a single
|
||||
markdown file. These topics *do* include the subtopics per file, but they
|
||||
are provided as properties of the top level topics as given.
|
||||
|
||||
Because the file topics take the first heading as the name as the topic
|
||||
name for the whole file, the first heading is not represented duplicitously
|
||||
within the sub topics owned by a file topic. (It is simply promoted to the
|
||||
file level)
|
||||
|
||||
### Header Topics
|
||||
|
||||
As a header topic tree. in this form, all of the topics that are found in any
|
||||
markdown file are included in a hierarchic form. However, a file may contain
|
||||
multiple topics at the same top level. This form does not include all the
|
||||
file topics above as containers of their respective header topics. All headers
|
||||
at the top-most level of topics are provided, even if there are multiple topics
|
||||
that tie for the top-most level in a given file.
|
||||
|
||||
Since header structure within a markdown file is not generally strictly kept,
|
||||
the header levels are *scrunched* before being presented. This means that,
|
||||
starting from the top, each header that is a direct subtopic is hoisted up
|
||||
to the next available level number such that there are no skipped levels. This
|
||||
makes presentation of topics much easier for rendering.
|
||||
|
||||
## Naming
|
||||
|
||||
Within the view model, these elements are named
|
||||
|
||||
- topics.list
|
||||
- topics.headers
|
||||
- topics.files
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
@@ -1,7 +0,0 @@
|
||||
# Parent Template Example
|
||||
|
||||
{{# inner }}
|
||||
- inner.rendered {{ rendered }}
|
||||
- target: {{ target }}
|
||||
- path: {{ path }}
|
||||
{{/ inner }}
|
||||
@@ -1,3 +0,0 @@
|
||||
# example header
|
||||
|
||||
Example paragraph
|
||||
@@ -1,3 +0,0 @@
|
||||
{{# fs.paths }}
|
||||
- [{{.}}]({{.}})
|
||||
{{/ fs.paths }}
|
||||
@@ -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
|
||||
```
|
||||
@@ -1,3 +0,0 @@
|
||||
# example header
|
||||
|
||||
Example paragraph
|
||||
@@ -1,3 +0,0 @@
|
||||
{{# paths }}
|
||||
- '{{ . }}'
|
||||
{{/ paths }}
|
||||
@@ -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.
|
||||
@@ -1,8 +0,0 @@
|
||||
<html>
|
||||
<head>Example Mustache Rendering directly to HTML</head>
|
||||
<body>
|
||||
<p>
|
||||
<span>The target is '{{ target }}'</span>
|
||||
</p>
|
||||
</body>
|
||||
</html>
|
||||
@@ -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 } }
|
||||
}
|
||||
}
|
||||
@@ -1,6 +0,0 @@
|
||||
<HTML>
|
||||
<HEAD>Heading Test</HEAD>
|
||||
<BODY>
|
||||
{{{ inner.rendered }}}
|
||||
</BODY>
|
||||
</HTML>
|
||||
@@ -1 +0,0 @@
|
||||
# Topic 1.1
|
||||
@@ -1 +0,0 @@
|
||||
# Topic 1.2
|
||||
@@ -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 }}
|
||||
}
|
||||
}
|
||||
@@ -1 +0,0 @@
|
||||
# Topic 2.1
|
||||
@@ -1 +0,0 @@
|
||||
# Topic 2.2
|
||||
@@ -1,12 +0,0 @@
|
||||
# Topics as list
|
||||
|
||||
{{# topics.list }}
|
||||
- name: {{ name }}
|
||||
- path: {{ path }}
|
||||
- level: {{ level }}
|
||||
{{/ topics.list }}
|
||||
|
||||
# Topics as Headers
|
||||
|
||||
# Topics as Files
|
||||
|
||||
@@ -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>
|
||||
|
||||
|
||||
@@ -1 +0,0 @@
|
||||
<em>{{{ inner.rendered }}}</em>
|
||||
@@ -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.
|
||||
@@ -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`.
|
||||
@@ -1,11 +0,0 @@
|
||||
## Begin Hierarchic Wrapping Layer
|
||||
|
||||
```
|
||||
inner.rendered follows
|
||||
```
|
||||
|
||||
{{ inner.rendered }}
|
||||
|
||||
```
|
||||
End Hierarchic Wrapping Layer
|
||||
```
|
||||
@@ -1,15 +0,0 @@
|
||||
### begin local wrapping layer
|
||||
|
||||
```
|
||||
inner.rendered follows
|
||||
```
|
||||
|
||||
{{ inner.rendered }}
|
||||
|
||||
```
|
||||
inner.rendered ends
|
||||
```
|
||||
|
||||
|
||||
### end local wrapping layer
|
||||
|
||||
@@ -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.
|
||||
@@ -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`.
|
||||
@@ -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 }}
|
||||
}
|
||||
}
|
||||
@@ -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>
|
||||
@@ -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
Reference in New Issue
Block a user