Write Forms with Formcode Syntax

onegov.form includes it’s own markdownish form syntax, inspired by https://github.com/maleldil/wmd

The goal of this syntax is to enable the creation of forms through the web, without having to use javascript, html or python code.

Also, just like Markdown, we want this syntax to be readable by humans.

How it works

Internally, the form syntax is converted into a YAML file, which is in turn parsed and turned into a WTForms class. We decided to go for the intermediate YAML file because it’s easy to define a Syntax which correctly supports indentation. Our pyparsing approach was flimsy at best.

Parser Errors

There’s currently no sophisticated error check. It’s possible that the parser misunderstand something you defined without warning. So be careful to check that what you wanted was actually what you got.



Every field is identified by a label, an optional ‘required’ indicator and a field definition. The Label can be any kind of text, not including * and =. The * indicates that a field is required. The = separates the identifier from the definition.

A required field starts like this:

My required field * =

An optional field starts like this:

My optional field =

Following the identifier is the field definition. For example, this defines a textfield:

My textfield = ___

Comments can be added beneath a field, using the same indentation:

My textfield = ___
<< Explanation for my field >>

All characters are allowed except ‘’>’’.

Complex example:

Delivery * =
    (x) I want it delivered
        Alternate Address =
            (x) No
            ( ) Yes
                Street = ___
                << street >>
                Town = ___
        << Alt >>
    ( ) I want to pick it up
<< delivery >>

Kommentar = ...
<< kommentar >>

All possible fields are documented further below.


Fields are grouped into fieldsets. The fieldset of a field is the fieldset that was last defined:

# Fieldset 1
I belong to Fieldset 1 = ___

# Fieldset 2
I belong to Fieldset 2 = ___

If no fieldset is defined, the fields don’t belong to a fieldset. To stop putting fields in a fieldset, define an empty fieldeset:

# Fieldset 1
I belong to Fieldset 1 = ___

# ...
I don't belong to a Fieldset = ___

Available Fields


A textfield consists of exactly three underscores:

I'm a textfield = ___

If the textfield is limited in length, the length can be given:

I'm a limited textfield = ___[50]

The length of such textfields is validated.

Additionally, textfields may use regexes to validate their contents:

I'm a numbers-only textfield = ___/^[0-9]+$

You can combine the length with a regex, though you probably don’t want to:

I'm a length-limited numbers-only textfield = ___[4]/^[0-9]+$

This could be simplified as follows:

I’m a length-limited numbers-only textfield = ___/^[0-9]{0,4}$

Note that you don’t need to specify the beginning (^) and the end ($) of the string, but not doing so might result in unexpected results. For example, while ‘123abc’ is invalid for ___/^[0-9]+$, it is perfectly valid for ___/[0-9]+. The latter only demands that the text starts with a number, not that it only consists of numbers!


A textarea has no limit and consists of exactly three dots:

I'm a textarea = ...

Optionally, the number of rows can be passed to the field. This changes the way the textarea looks, not the way it acts:

I'm a textarea with 10 rows = ...[10]


A password field consists of exactly three stars:

I'm a password = ***


An e-mail field consists of exactly three @:

I'm an e-mail field = @@@


An url field consists of the http/https prefix:

I'm an url field = http://
I'm the exact same = https://

Whether or not you enter http or https has no bearing on the validation.


A date (without time) is defined by this exact string: YYYY.MM.DD:

I'm a date field = YYYY.MM.DD

Note that this doesn’t mean that the date format can be influenced.

A date field optionally can be limited to a relative or absolute date range. Note that the edges of the interval are inclusive. The list of possible grains for relative dates are years, months, weeks and days as well as the special value today.

I’m a future date field = YYYY.MM.DD (+1 days..) I’m on today or in the future = YYYY.MM.DD (today..) At least two weeks ago = YYYY.MM.DD (..-2 weeks) Between 2010 and 2020 = YYYY.MM.DD (2010.01.01..2020.12.31)


A date (with time) is defined by this exact string: YYYY.MM.DD HH:MM:

I'm a datetime field = YYYY.MM.DD HH:MM
I'm a futue datetime field = YYYY.MM.DD HH:MM (today..)

Again, this doesn’t mean that the datetime format can be influenced.

The same range validation that can be applied to date fields can also be applied to datetime. Note however that the Validation will be applied to to the date portion. The time portion is ignored completely.


A Time is defined by this exact string: HH:MM:

I'm a time field = HH:MM

One more time, this doesn’t mean that the datetime format can be influenced.


There are two types of number fields. An integer and a float field:

I'm an integer field = 0..99
I'm an integer field of a different range = -100..100

I'm a float field = 0.00..99.00
I'm an float field of a different range = -100.00..100.00

Integer fields optionally can have a price attached to them which will be multiplied by the supplied integer.

Number of stamps to include = 0..30 (0.85 CHF)


To write code in a certain syntax, use the following:

Description = <markdown>

Currently, only markdown is supported.


A file upload is defined like this:

I'm a file upload field = *.*

This particular example would allow any file. To allow only certain files do something like this:

I'm a image filed = *.png|*.jpg|*.gif
I'm a document = *.doc
I'm any document = *.doc|*.pdf

The files are checked against their file extension. Onegov.form also checks that uploaded files have the mimetype they claim to have and it won’t accept obviously dangerous uploads like binaries (unless you really want to).

Standard Numbers

onegov.form uses python-stdnum to offer a wide range of standard formats that are guaranteed to be validated.

To use, simply use a #, followed by the stdnum format to use:

I'm a valid IBAN (or empty) = # iban
I'm a valid IBAN (required) * = # iban

The format string after the # must be importable from stdnum. In other words, this must work, if you are using ch.ssn (to use an example):

$ python
>>> from stdnum.ch import ssn

This is a bit of an advanced feature and since it delegates most work to an external library there’s no guarantee that a format once used may be reused in the future.

Still, the library should be somewhat stable and the benefit is huge.

To see the available format, have a look at the docs: https://arthurdejong.org/python-stdnum/doc/1.1/index.html#available-formats

Radio Buttons

Radio button fields consist of x radio buttons, out of which one may be preselected. Radio buttons need to be indented on the lines after the definition:

Gender =
    ( ) Female
    ( ) Male
    (x) I don't want to say

Radio buttons also have the ability to define optional form parts. Those parts are only shown if a question was answered a certain way.

Form parts are properly nested if they lign up with the label above them.

For example:

Delivery Method =
    ( ) Pickup
        Pickup Time * = ___
    (x) Address
        Street * = ___
        Town * = ___

Here, the street and the town only need to be provided, if the delivery method is ‘Address’. If the user selects a different option, the fields are not shown and they will not be required.

On the other hand, if ‘Pickup’ is selected, the ‘Pickup Time’ needs to be filled out and the address options are hidden.

This kind of nesting may continue ad infinitum. Meaning you can nest radio buttons as deeply as you like. Note however, that this is discouraged and that your users will not be too happy if you present them with a deeply nested form.

More than one level of nesting is a clear indicator that your form is too complex.


Checkboxes work exactly like radio buttons, just that you can select multiple fields:

Extras =
    [x] Phone insurance
    [ ] Phone case
    [x] Extra battery

Just like radiobuttons, checkboxes may be nested to created dependencies:

Additional toppings =
    [ ] Salami
    [ ] Olives
    [ ] Other
        Description = ___

Pricing Information

Radio buttons and checkboxes may be priced. For example, the following order form can be modeled:

Node Size =
    ( ) Small (20 USD)
    (x) Medium (30 USD)
    ( ) Large (40 USD)

Extras =
    [x] Second IP Address (20 CHF)
    [x] Backup (20 CHF)

Delivery =
    (x) Pickup (0 CHF)
    ( ) Delivery (5 CHF!)

The additional pricing metadata can be used to provide simple order forms. As in any other form, dependencies are taken into account.

The optional ! at the end of the price indicates that credit card payment will become mandatory if this option is selected. It is possible to achieve this without a price increase too: (0 CHF!)