# My website platform

I use this custom layer on top of PUG for my personal web page. It allows you to write full HTML pages, as well as simple markdown pages.

## How to use?

Using Deno, just running `src/main.ts` with an argument to the config file will start the server. The config consists of the following fields:

- ignore: consists of a list of paths that should be invisible to the public
- plugins: a list of plugins that should be loaded
- libs: a path to the folder which contains the plugins
- views: a path to the folder which contains the views
- maxCache: how many seconds should pass, before a cached page is discarded
- debug: If true, will output more information
- static: If provided, will be a path which contains statically-served resources

- notFound: The name of the not found page
- defaultPage: The name of the page template (the template for a file)
- defaultIndex: The name of the index template (the template for a folder)
- defaultTitle: If the page has no title, this will be used instead

- Everything else: Will become a default value for a global variable

### Structure

There is one folder - the views folder, which contains the files that will be rendered and served by the server. Resolving a view is not too different from resolving a NodeJS module - the server will search for these paths, in this order:

- ${viewsDir}/${path}/index.pug
- ${viewsDir}/${path}/index.md
- ${viewsDir}/${path}.pug
- ${viewsDir}/${path}.md
- ${viewsDir}/${notFound}.pug
- ${viewsDir}/${notFound}.md
- (built-in fallback error message)

The first path that is found will be used as the rendered file. If the found file is an index file, it will be rendered with the index base, otherwise, the page base will be used instead.

First things first, the server will resolve the metadata that the view provides (if any). That metadata will be overlaid over the config and will be used to resolve the base of the page. After that, our view will be rendered, and the output will be put in the metadata option "text". Of course, having a base page that is not `pug` would be useless, as markdown has no templating capabilities.

In a pug view, you will be able to access all metadata and config as global variables. The metadata will be overlaid over the global config.

In a JS view, you will be able to access the following relevant modules, which will allow you to get information about the current view:
- !lib
	- View - the base class for all views
	- config - the global config
	- isIgnored - a function that checks whether the given path is ignored
	- list - a utility function that converts an unknown value to a set of strings
	- getPlugin - gets the function that calls a plugin (we will talk about them later)
	- getLocals - gets an object, representing the current running metadata
	- resolveView - from a given URL, returns the corresponding View object
	- resolveViewFromUri - from a given filesystem path, returns the corresponding View object
	- type Plugin
	- type Locals
	- default.View - same as View
	- default.config - same as config
	- default.isIgnored - same as isIgnored
	- default.locals - a getter that calls getLocals

### Plugins

Plugins are used to provide additional reusable functionality for the views. They can be put in the configured plugins folder. Due to how the import system works, all plugins that will be used need to be listed in the config (they will be preloaded). A plugin must have its default export a function. That function will take a view as its first argument, and additional user-defined arguments. The function may return anything

Invoking plugins in Pug code can be done with the additionally exposed function `invoke(name, ...args)`. The current view will be passed as the first argument of the plugin.

## Deploying

It is as simple as building, using the included Dockerfile.