mirror of
https://github.com/nosqlbench/nosqlbench.git
synced 2025-02-25 18:55:28 -06:00
removed old docsys design and test files
This commit is contained in:
@@ -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,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,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
@@ -1,9 +0,0 @@
|
||||
+++
|
||||
title: Example Title (TOML)
|
||||
+++
|
||||
|
||||
# Header1
|
||||
|
||||
A Synopsis
|
||||
|
||||
## Header2ile
|
||||
@@ -1,9 +0,0 @@
|
||||
---
|
||||
title: Example Title (YAML)
|
||||
---
|
||||
|
||||
# Header1
|
||||
|
||||
A Synopsis
|
||||
|
||||
## Header2
|
||||
Reference in New Issue
Block a user