AlderconeStudio/heckweasel
0
0
Fork 0
Code Issues 2 Pull Requests Packages Projects Releases Wiki Activity

Initial chekin post-discontinuity.

Browse Source
This commit is contained in:
Administrative Account
2023-09-25 12:16:34 -07:00
commit 694acf8599
36 changed files with 2118 additions and 0 deletions
Download Patch File Download Diff File Expand all files Collapse all files

65
docs/index.html Normal file
View File

@ -0,0 +1,65 @@
<h1>HECKWEASEL documentation!</h1>
<p>Welcome to the index for HECKWEASEL Documentation. In this directory you&rsquo;ll find a bunch of files but this is the introduction you need to understanding the way heckweasel works and how to use it.</p>
<h2>Introduction Part 2: What the hyeck is Heckweasel?!</h2>
<p>Heckweasel is a website compiler framework. Primarily it allows the creation of web site using a collection of flat files which are in a maintainable form, producing the less maintainable formats that web browsers use.</p>
<p>The flat files in a heckweasel project are just a directory of files like any other. There is a default directory structure for projects but that isn&rsquo;t important right now.</p>
<p>Heckweasel projects generally take the form of a collection of one or more templates and a collection of one or more files that are filled into the templates. Pervasively, heckweasel draws a distinction between the contents of a web page and the template it gets put into. You can think of the template, as generally used by heckweasel, as a sort of picture frame into which your content is placed. The content itself may be implemented as one of several popular formats such as Markdown and HTML. Also of note is that there are sort of two routes from heckweeasel input to heckweasel output, one route is through the template system and the other route merely copies the input to the output.</p>
<p>Another important detail about heckweasel is metadata. Every item in the heckweasel project (thus, every file in the heckweasel project directory) has a collection of <em>metadata</em> associated with it, such as its file name, creation time, and other objective information, but also any arbitrary information about it such as its title, a short description, thumbnails or whatever. It&rsquo;s also important to note that the <strong>content</strong> of a file counts as metadata, and is stored the same way inside of heckweasel&rsquo;s way of looking at the files. Metadata is stored with the file as <em>filename</em>.meta and directories contain metadata in the file called .meta. Metadata is also inherited! So setting a template in a directory&rsquo;s metadata will apply to all of the contents of that directory. Metadata is all in a JSON format called JStyleSon, which is JSON except you can have comments in it. All of these metadata are accessable from the templates, which leads to&hellip;</p>
<p>The final important detail about heckweasel is that it, at is core, uses a programmable template system called Jinja. Jinja allows a lot, and I mean a <em>lot</em> of flexability in the way that the output is produced, giving complete programmability. This allows templates (and pages, for that matter) to contain programmable outcomes such as showing a list of all blog entries (each of which would be a separate file), or making a thumbnail gallery from a collection of pictures, or generating an RSS feed from all of the contents of the site. This also allows the website design to be broken into parts such that commonly-used patterns can be merely included in the file rather than being written repeatedly (although normally this function done with the page templates).</p>
<h2>Just the very Basic Heckweasel Project</h2>
<p>So with all of that said, the most basic possible heckweasel project that is actually functional would be something like a page template, and a content file called index. Heckweasel operates on an input directory and outputs to an output directory. This is admittedly not a normal use case since it doesn&rsquo;t benifit much from the elaborate system underneath, but it gets the idea across.</p>
<p>So you have your project directory <code>mywebsite</code>; inside we can have the directories <code>source</code> and <code>publish</code>, and various files, and well here&rsquo;s a picture:</p>
<ul>
<li><strong>mywebsite</strong>
<ul>
<li><strong>source</strong>
<ul>
<li><em>.meta</em></li>
<li><strong>templates</strong>
<ul>
<li><em>default.jinja</em></li>
</ul>
</li>
<li><em>index.md</em></li>
<li><em>index.md.meta</em></li>
</ul>
</li>
<li><strong>publish</strong></li>
</ul>
</li>
</ul>
<p>To explain the various files:</p>
<h3><em>.meta</em></h3>
<p>This file is a JSON file containing project-wide metadata. Usually this would be metadata that applies, by default, to all files. Some things that affect the way Heckweasel processes files would be <code>template</code> which would set the default template to put content into and <code>templates</code> which would set the directory to look for templates in. By custom we also may want to set the title, author and other things like that which we may want to fill into the output files. We also put things like the eventual published address for the site (<code>site_root</code>).</p>
<p>Example .meta file:</p>
<p>```json</p>
<p>{
&ldquo;site_root&rdquo;: &ldquo;https://website.me&rdquo;,
&ldquo;author&rdquo;: &ldquo;Very Nice Person&rdquo;,
&ldquo;title&rdquo;: &ldquo;My Website&rdquo;
}</p>
<p>```</p>
<h3><em>default.jinja</em></h3>

151
docs/index.md Normal file
View File

@ -0,0 +1,151 @@
# HECKWEASEL documentation!
Welcome to the index for HECKWEASEL Documentation. In this directory you'll find a bunch of files but this is the introduction you need to understanding the way heckweasel works and how to use it. You wouldn't web a site.
## Introduction: TL;DR
Heckweasel compiles a set of files into a website.
There is your website **template**, separate files that are the **content** of your website (such as a blog post, an image, etc), and json files that are the **metadata** for each content file. These get compiled together into static web pages.
There's a lot more to it, and it is entirely programmable, but basically that's it.
## Introduction: What the hyeck is Heckweasel?!
Heckweasel is a website compiler framework. Primarily it allows the creation of web site using a collection of flat files which are in a maintainable form, producing the less maintainable formats that web browsers use.
The flat files in a heckweasel project are just a directory of files like any other. There is a default directory structure for projects but that isn't important right now.
Heckweasel projects generally take the form of a collection of one or more templates and a collection of one or more files that are filled into the templates. Pervasively, heckweasel draws a distinction between the contents of a web page and the template it gets put into. You can think of the template, as generally used by heckweasel, as a sort of picture frame into which your content is placed. The content itself may be implemented as one of several popular formats such as Markdown and HTML. Also of note is that there are sort of two routes from heckweeasel input to heckweasel output, one route is through the template system and the other route merely copies the input to the output.
Another important detail about heckweasel is metadata. Every item in the heckweasel project (thus, every file in the heckweasel project directory) has a collection of *metadata* associated with it, such as its file name, creation time, and other objective information, but also any arbitrary information about it such as its title, a short description, thumbnails or whatever. It's also important to note that the **content** of a file counts as metadata, and is stored the same way inside of heckweasel's way of looking at the files. Metadata is stored with the file as *filename*.meta and directories contain metadata in the file called .meta. Metadata is also inherited! So setting a template in a directory's metadata will apply to all of the contents of that directory. Metadata is all in a JSON format called JStyleSon, which is JSON except you can have comments in it. All of these metadata are accessable from the templates, which leads to...
The final important detail about heckweasel is that it, at is core, uses a programmable template system called Jinja. Jinja allows a lot, and I mean a *lot* of flexability in the way that the output is produced, giving complete programmability. This allows templates (and pages, for that matter) to contain programmable outcomes such as showing a list of all blog entries (each of which would be a separate file), or making a thumbnail gallery from a collection of pictures, or generating an RSS feed from all of the contents of the site. This also allows the website design to be broken into parts such that commonly-used patterns can be merely included in the file rather than being written repeatedly (although normally this function done with the page templates).
## Glossary
- **template**
- A -link-Jinja2 file which gets filled in with your content
- **content**
- The content which gets filled into templates to produce pages
- **metadata**
- Extra variables or values associated with content, which can be used to modify the way template works and do other tricks
## Just the very Basic Heckweasel Project
So with all of that said, the most basic possible heckweasel project that is actually functional would be something like a page template, and a content file called index. Heckweasel operates on an input directory and outputs to an output directory. This is admittedly not a normal use case since it doesn't benifit much from the elaborate system underneath, but it gets the idea across.
So you have your project directory `mywebsite`; inside we can have the directories `source` and `publish`, and various files, and well here's a picture:
- __mywebsite__
- __source__
- *.meta*
- __templates__
- *default.jinja*
- *index.md*
- *index.md.meta*
- __publish__
To explain the various files:
### *.meta*
This file is a JSON file containing project-wide metadata. Usually this would be metadata that applies, by default, to all files. Some things that affect the way Heckweasel processes files would be `template` which would set the default template to put content into and `templates` which would set the directory to look for templates in. By custom we also may want to set the title, author and other things like that which we may want to fill into the output files. We also put things like the eventual published address for the site (`site_root`).
Example .meta file:
```json
{
"site_root": "https://website.me",
"author": "Very Nice Person",
"title": "My Website"
}
```
### *default.jinja*
This is the default template. Heckweasel will look for `templates/default.jinja` unless another templates directory and template are specified. Jinja templates might output any kind of text file you want, but usually we put HTML inside them. Here's an example `default.jinja` that makes a barely functional web page but we'll explain more later:
```jinja2
<!DOCTYPE html>
<html>
<head>
<title>{{ metadata.title }}</title>
</head>
<body>
{{content}}
</body>
</html>
```
The main thing to notice is that this is a very simple HTML file. It does the bare minimum to render in a browser. The next thing to notice are all of the `{}` things. Those are Jinja commands. A `{{}}` containing a name will fill that name from the variables set in the Jinja environment. In Heckweasel the main two things are `content` and `metadata`. `Metadata` contains the metadata set via the `.meta` and other sources as discussed above. The new thing here is `content`, which is the *contents* of the page! As discussed above, the contents and template are considered separately, and so the page contents are filled into the template where the `{{content}}` tag is! You can also see that the title of the page is set based on the page's `title` metadata. We'll discuss this more in the next section.
Another interesting thing is, any styling that should be applied to the whole website, to a particular page type, or whatever goes in templates. For example this is where you'd include the site-wide CSS sheet for this site, and it would apply that style to all the pages (we'll discuss this more in a future section).
### *index.md*
This is the contents of the page that will eventually become `index.html` when heckweasel is done with it. Notice it is `.md` which means markdown, a user-friendly markup format - heckweasel will convert this to an HTML fragment and fill in the template's `content` with the result, producing `index.html`. This is how the magic happens! The contents of this file could be something as simple as:
```markdown
# Welcome!
Hello this is my website! Hi!
```
### *index.md.meta*
This contains the metadata specific to `index.md`. It can be left out if there isn't any specific metadata, but it's useful to make even an empty one for future reference. An example use of this is to set different title for each page.
Example:
```json
{
"title": "Welcome to my Home Page"
}
```
### Rolling it all together
Given the above tree, from the command line in the `mywebsite` directory, to compile this would be as simple as :
```bash
$ python -mheckweasel source publish
```
This would produce, in the `publish` directory, `index.html`, which would have contents like:
```html
<!DOCTYPE html>
<html>
<head>
<title>Welcome to my Home Page</title>
</head>
<body>
<h1>Welcome!</h1>
<p>This is my website! Hi!</p>
</body>
</html>
```
Notice how the result of converting `index.md` into HTML is inserted into the template where `{{content}}` was, and the value of `title` from `index.md.meta` is inserted where `{{metadata.title}}`. While `index.md` inherited the top-level `title` metadata from the top `.meta`, its own `index.md.meta` file overrode it. Neat!
The `publish` directory is ready to be serverd by a small HTTP server, placed in a web content directory, or whatever. We'll discuss that in a future section about hosting your Heckweasel site.
## Getting (very slightly) more advanced with Heckweasel
Now that we see how a project and its parts fit together we can make our little website slightly more interesting.
### Styling your Web Site
As we alluded to above, the templates are where style information generally lives.

77
docs/metadata.md Executable file
View File

@ -0,0 +1,77 @@
# METADATA #
## FORMAT ##
Metadata is stored as a JSON file which allows C-likecomments.
Metadata is loaded from the top down, so each parent from the root can impart metadata on children. Children can explitily nullify parent metadata by
assigning it to undefined.
## STORAGE ##
On-disk meatdata is stored as a file along side the non-metadata file with the extension '.meta', for example the file 'foo.thtml' would have a metadata file as 'foo.thtml.meta'. Metadata for directories (which gets applied to all contents of that directory) is stored in .meta in the directory.
## DEFAULT KEYS AND VALUES ##
All files define the following keys by default:
relpath
: The relative path to the root of the site, useful for prepending to image `src=` and other resource paths such as CSS files and fonts in order to maintain locally viewable output.
file_name
: The local path of the file
file_path
: The full path to the file from the root
dir
: The directory to the path from root for this file
os-path
: The native OS path to this file
guessed-type
: The guessed mime-type of the file
stat
: A tree of stat() values in a dictionary, without the ST_ prefix, and with lowercase keys.
templates
: The path to the template files.
uuid
: A UUID for this file based on its path and a specified `uuid-oid-root` metadata
build-time
: The time stamp for the build time
Files can also explicitly override these which are set to empty defaults:
mime-type
: Either the specified mime-type or guessed type if undefined.
template
: The full path to the template file
dir-template
: The full path to the filesystem template
title
: A title for this object derived from the template, metadata or other sources.
summary
: A summary of the file contents.
description
: A description of file contents.
Trees have some metadata that projects should probably override (generally in their top-level .meta):
uuid-oid-root
: A string added to the beginning of the path that identifies this site, used for deriving OID UUIDs.
author
: The full name of the author of this site (should also be overridden per-file if necessary).
author_email
: The email of the author of this site (see above)
site_root
: The full URL for the root of this web site used for links and whatnot, with ending slash.
Special Keys that can be defined, these change the processing in predictable ways:
type
: Define that the file that this metadata is applied to as a specific type from the type mapping table. Useful values are `passthrough` and `templatable` with obvious outcomes.
wildcard_metadata
: Define a dictionary of file globs (patterns which match files such as `*.txt`), with the value being a dictionary of additional metadata to apply to the matched files. This is generally
defined at the top level of the project to make certain file patterns treated as special without having to give them their own metadata.
## CACHING STRATEGY ##
The tree is traversed from the top down, each node in the tree is stat(). The mtime walue is compared to the mtime stored in the cache dict for that node. If it is newer, the metadata
is loaded again, and the tree continues to traverse.

5
docs/patterns.md Normal file
View File

@ -0,0 +1,5 @@
# Patterns for Site Design #
These are some simple patterns for things commonly needed in websites of various kinds.
##

71
docs/project-layout.md Normal file
View File

@ -0,0 +1,71 @@
# Project Layout #
It is recommended that in general your project for Heckweasel site be layed out like:
```
project_top/
Makefile - Convenient for building your site
src/ - All "source" pages are contained in here.
.meta - Top-level default metadata is set here
index.cont - The content part of the index page
index.cont.meta - A metadata json file for the index, specifically.
templates/ - Templates go in here
default.jinja2 - Default template that will be used if none are specified
publish/ - The path the build process will create, where the post-processed files go.
```
## Makefile ##
Makefile is suggested, but not essential, for encapsulating your build commands to produce your
site. Something as simple as:
```
build: src/templates/* src/*
python -mheckweasel src publish
```
## src/ ##
This is the top level path that all of your templates, page fragments, images, etc. will be stored. This is basically the "source code" for your site.
## src/.meta ##
This is the top level metadata that is used as the default for all subsidiary metadata. It is in JSON format (with JS style comments). See <METADATA.md> for more information.
Example .meta file:
```
{
"title": "My Website", // this is the default title applied if none are specified
"author": "Super Web Dude",
"site_root": "http://example.com",
"uuid-oid-root": "example.com-", // this is used to generate UUIDs
}
```
## src/templates/ ##
Templates are all stored here, as this is the search path for Jinja.
## templates/default.jinja2 ##
If a page specifies a `template` metadata key, the named template is used, however, if not this template is used. Generally speaking this is a complete HTML file, with the `{{ content }}` template string placed where the content of subsidiary pages will be embedded.
A simple default.jinja2 example:
```
<!DOCTYPE html>
<html>
<head>
<title>{{ metadata.title }}</title>
</head>
<body>
{{content}}
</body>
</html>
```
## publish/ ##
This is arbitrary, and will be created by heckweasel at build time, but it will be the root path that should be published to your web server.

10
docs/quickstart.md Normal file
View File

@ -0,0 +1,10 @@
# I am just writing a simple site with a couple of pages
# I am interested in the technicalities of template development
# I am interested in the technicalities of deployment

113
docs/templatefunctions.md Normal file
View File

@ -0,0 +1,113 @@
# Template Functions #
These are functions exposed to the templates which perform various useful actions for the site designer.
## get_file_list ##
Return a list of file names based on a wildcard glob, matched against the root of the project.
Prototype: `get_file_list(file_glob, sort_order, reverse, limit) -> [files]`
Arguments:
* file_glob: A standard file glob, for example `*.txt` matches all files that end in `.txt` in the root of the project. (default: `*`)
* sort_order: A string of either `file_path`, `file_name`, `ctime`, `mtime`, `size` and `ext` (default: `ctime`)
* reverse: whether the sort is reversed (default: False)
* limit: The number of entries to return from the top of the list, 0 for unlimited (default: `0`)
Returns:
* A list of file names.
## get_file_name ##
Return the filename that will result from processing the specified file based on the processors that it will be passed through.
Prototype: `get_file_name(file) -> outfile`
Arguments:
* file: The name of a file, with path, from root.
Returns:
* outfile: The name of the file, with path, that will result from processing.
## get_file_content ##
Return the rendered content of specified file. Caution: Can result in infinite loops if two templates include each other.
Prototype: `get_file_content(file) -> content`
Arguments:
* file: The name of the input file, with path, from root.
Returns:
* content: the contents that result from passing the specified file through its processors.
## get_raw ##
Return the raw contents of a source file. It is specifically not passed through any processing.
Prototype: `get_raw(file) -> content`
Arguments:
* file: The name of the input file, with path, from root.
Returns:
* content: the raw contents of the input file
## get_file_metadata ##
Return the metadata tree associated with a particular file.
Prototype: `get_file_metadata(file) -> metadata`
Arguments:
* file: the name of an input file, with path, from root
Returns:
* metadata: A dictionary of metadata loaded from the file tree.
## get_time_iso8601 ##
Return the date/time stamp in ISO 8601 format for a given time_t timestamp for UTC.
Prototype: `get_time_iso8601(timestamp) -> timestamp`
Arguments:
* timestamp: A time_t integer or float, in seconds since Jan 1 1970.
Returns:
* timestamp: A string in ISO8601 format of the date and timestamp, in the UTC timezone.
## get_date_iso8601 ##
Return the date stamp in ISO 8601 format for a given time_t timestamp for UTC.
Prototype: `get_date_iso8601(timestamp) -> timestamp`
Arguments:
* timestamp: A time_t integer or float, in seconds since Jan 1 1970.
Returns:
* timestamp: A string in ISO8601 format of the date stamp, in the UTC timezone.
## pygments_get_css ##
Return a blob of CSS produced from Pygments for a given `style`.
Prototype: `pygments_get_css(style) -> css`
Arguments:
* style (optional): A style identifier for the Pygments' HTMLFormatter.
Returns:
* css: A string of styles as returned by Pygments' HTMLFormatter.
## pygments_markup_contents_html ##
Format a code fragment with Pygments
Prototype: `pygments_markup_contents_html(input, filetype, style) -> html`
Arguments:
* input: A string containing the code to format (either literal, or imported with get_raw()).
* filetype: A string describing which lexer to use.
* style (optional) A style identifier for Pygments' HTMLFormatter.