Ask any old unix beard how much preprocessor code is a dignified amount and they will likely tell you as little as possible. In fact, since C++, no new major programming languange has used a preprocessor and that for good reason.
Except HTML templating that is. For some reason we still gladly suffer 1950's style development tools when we generate HTML. Why is that?
Gjut is a semantic templating language. This means unlike ordinary templating systems like rhtml or velocity, it cares whether you produce proper html.
So far Gjut is merely an experiment to make a point.
- Node.js
- PEG is a javascript parser generator.
- stdio is used in gjutc for command line parsing.
- nodeunit runs the tests.
- GNU Make is optional.
Gjut comes with an example command line compiler.
$ ./bin/gjutc example/index.html
Imports a javascript module.
@import dir.file
Loads dir/file.js
Inserts an html file.
@insert header.html
Assuming the module modulename returns
return {
foobar: 'Hello, world!'
}
the variable @modulename.foobar can be inserted as an element content and will render Hello, world!.
The call to gjut.render_html() also takes an object of local variables from the user. Assuming passing something like
gjut.render_local(template, {'local': 'My local var'}, context)
The variable @local will be replaced.
Assuming your module returns:
return {
func: function(element) {
element.attributes['id'] = ['syntheticId'];
}
}
The input
<div @modulename.func()></div>
will render as:
<div id="syntheticId"></div>
Assuming your module returns:
return {
listItem: function listItem(element, i) {
element.content.push({
type: 'text',
content: '=== ' + i + " ==="
});
}
array: ['foo', 'bar', 'baz']
}
and your html contains
<li @foreach(@variables.listItem() in @variables.array)></li>
the output will be
<li>
=== foo ===
</li>
<li>
=== bar ===
</li>
<li>
=== baz ===
</li>
The structural nature of a compiled template means that verification can be performed on the static template before rendering. In theory dynamic verification after code execution is also possible but at at performance cost. This is not implemented.
@verify .carousel -> .canvas
Implies that if there is an element with class carousel there must also be somewhere in it tree of subelements an element with class canvas. Normal css selectors apply so #foo looks for id="foo" and div means any element div.
@verify .carousel <- .canvas
Means any element with class canvas must have in its parent chain an element with class carousel.
@verify exist #carousel
Will fail unless there in the compiled template is an element with id carousel. sub-templates from the use of the @insert macro will also be checked.
@verify type .carousel[width]: int
Checks that the type of the data-attribute data-width contains a single value and that this value produces a number when converted to int using javascripts parseInt() method.