Feed Icon RSS 1.0 XML Feed available

DRAEM: Domain Specific Toolchain for Web Generation

Tags: ,

Draem
DRAEM is a static website builder, which is along the lines of something like Jekyll...but using open source Rebol 3. Blog entries (or pages) are written in a "dialect" of the language, so despite their customized appearance they have no parser of their own. Rather, they embrace the carefully-chosen limits of the host system to create a Domain-Specific Language.
The tool is mostly notable for the reasons Rebol is notable. This includes depending only on a half-megabyte, zero-install, cross-platform executable that can run on Linux, Android, HaikuOS, Windows, Mac, etc.
If you are the sort of person who just clicks "yes" to installing packages or DLLs without concern about size or dependencies, the biggest advantages of Draem will probably be off your radar. But if you think these matters are worth considering, perhaps it's worth looking at to see how it works. Rebol 3 was open sourced in December of 2012, and a compiled variant called Red is under heavy development.

History

Draem was initially designed as a simple system for making a website which facilitated the easy authoring of a stylized "screenplay" format of blogging. This was primarily for journaling lucid dreams, biased toward a traditional "movie script" style. It was expanded to support things like code samples, and has continued to be tuned and tweaked.
A question that could be asked is what value this tool has compared to Jekyll (or things like it). Well...
{...an important thing is that it has *more structure*, and a cleaner model for evolving}

[you: <surprised> {Wait, it supports things like dialogue?}]

[me: {Yes, in fact that was one of the things it was originally designed for.}]

[update 1-Jan-2014 {But it now powers hostilefork.com!}]
A string standing on its own is interpreted in MarkDown format. But if you put a series of symbolic tokens into a block, the system matches it against patterns. Rebol's linguistically rich nature opens a lot of doors for coming up with interesting dialects...the current implementation only scratches the surface.
Some other web-generation systems have been made in Rebol, many of which take text files as input. The reasoning is that having to express your thought in parseable "code" was too constraining as a markup language. I wanted to challenge that belief, and try working with the site content as Rebol. So far it has been quite natural.
The compromise I made was that strings would be allowed to use markdown, but this would be done on a paragraph level. There would still be what I call a "Rebol backbone", used for any greater structure needed in a document. As a result, it's fairly easy to write programs that do structural transformations on the data--a "metaprogramming" capability that you won't find in other tools.

Format

The input format is a series of blocks, representing sequential sections of the dream dialogue. The rule is that the behavior of any block that would accept a single item as legal is the same as omitting the block. So if you can write:
[Foo]
Then you could have just written:
Foo
However, you cannot omit the block if something takes options. So instead of writing:
[Foo FooOption]
You cannot just write:
Foo FooOption
Whitespace between items is ignored, per Rebol's rules. So a series of items are presumed to be different sections. So this would produce three separate "paragraphs", despite the lack of a newline:
{One} {Two} {Three}
Blocks can be used to group items in places where a single item would be expected. So for instance, this is ia legitimate way of passing two "groups" to Foo:
[Foo [{Baz} {Bar}] [{Mumble} {Frotz}]]
This is applicable to cases like bulleted lists, where you might want to put multiple sections under a single bullet. But most constructs do not require the blocks.

Dialect Types

In order to avoid having this information in more than one place, the dialect elements are described in the GitHub repository:

Future

Draem is more of an experiment than anything. How far it will go is not known. Other similar systems are being developed like Lest: Low Entropy System for Templating. Mission-wise, they are not that different...so Draem may wind up being a set of plug-ins for Lest eventually.
However, I am interested in seeing what kinds of tricks might be possible to do partial-page compilation. An idea I had was that Draem pages might use parentheses for evaluations, such as:
[{The sum of 1 + 2 is} (1 + 2) {and can be calculated at build time.}]
[{The user name is} (model/user) {and cannot.}]
The thought I had would be that the model would be defined as a function throwing a specific error if you tried to use it at compile time. The resulting partially-compiled template would then be evaluated on the server when requested, when the actual model was available. It would be a neat trick!
Business Card from SXSW
Copyright (c) 2007-2018 hostilefork.com

Project names and graphic designs are All Rights Reserved, unless otherwise noted. Software codebases are governed by licenses included in their distributions. Posts on blog.hostilefork.com are licensed under the Creative Commons BY-NC-SA 4.0 license, and may be excerpted or adapted under the terms of that license for noncommercial purposes.