jigo
Jigo is a Jinja2-like template language for Go. It is in pre-alpha stages and not
yet ready for use much less production. Any documentation you see here is subject
to change. Jigo's name is also subject to change.
Goals
The goal of jigo is to create a template system which is powerful, flexible, and
familiar. The Django template syntax has inspired Jinja2,
Twig in php, Liquid in Ruby, Jinja-JS in JavaScript,
and indeed Pongo2 in Go.
Although jigo is an outright attempt to implement a very functional subset of
Jinja2's semantics, the fact that it is written in Go means that much of Jinja2's
support for rich Python expressions and semantics are dropped.
Twig, a Jinja2-like template system implemented in PHP, allows for a limited
expression syntax which more closely mimics Python's than PHP's. Jigo allows for a
similarly Python-inspired expression syntax, with a clean, explicit two way mapping
to Go types and stronger type matching requirements.
Unlike Go's html/template, There are no plans and currently no support for
context-aware escaping. Because of html/template, this is a big deal for many
in the Go community, and while I'm not against adding it to Jigo, I am more interested
in getting the language in a usable state first.
- If you want logic-less templates, try moustache (note buggy and unmaintained)
- If you want execution safety, try liquid or mandira
- If you want contextually aware escaping, try html/template
- If you want something aiming to be compatible with django templates, try pongo2
Differences
There are many differences. Some infrequently used features of Jinja2 have
been dropped, and the expression syntax is far less sophisticated.
Features
- Line statements and line comments have been dropped
TODO More info here as I get through more of the implementation.
Type Safety
Template lookups are obviously not inspectable for types at compile time, but literals
are, and although there are no type declarations, all types are inferred according to
rules defined below. This means that the following code raises a type error at compile
time:
{{ 1 + "foo" }}
Expressions
Expressions are coerced to strings at render time with fmt.Sprint, but
expression syntax is strongly typed. Unlike Go, integer and floating point
arithmetic can be mixed, but any introduction of floats coerces all values
in the expression to float.
Function calling semantics allow for keyword arguments if the function's final
argument is of type jigo.Kwargs. Varargs are allowed if a funciton is variadic
or the final argument is of type jigo.Args. For a function to be both
variadic and keyword, it must accept (jigo.Args, jigo.Kwargs) in that order.
Jigo follows Go's operator precedence
and Go's definition of %, which is remainder, like C, and unlike
Python. % is only defined in integers, and will be a compile time error on
float literals and a runtime error on float variables.
Other Operators:
** is power, eg 2**4 = 16// is floor-div, eg. 14//3 = 4~ is a string concatenation object, which explicitly coerces both sides to
the string type via fmt.Sprintis will perform tests similar to Jinja2.in is only valid for array, slice and map types. It is linear on arrays and slices.[] is the selection operator, only valid on array, slice, and map types.. is the attribute operator, only valid on struct types.
Literals
- All integer numeric literals map to
int64 (beware overflow)
- All numeric literals with a "." in it become
float64
- Strings are standard " delimited, with \ escapes. No multi-line or ``
string syntax support.
- Lists are defined as
'[' expr [, expr]... ']', and map to the Go type []interface{}
- Hashes are defined as
'{' stringExpr ':' expr [, stringExpr ':' expr]... '}',
and map to map[string]interface{}. A stringExpr is an expression that is
coerced to a string automatically. This means that the "1" and 1 represent the
same key.
- No advanced python expressions/literals (comprehensions, sets, generators, etc).
