about processes and engines


My task as a programmer seems mostly to be throwing forms at knowledge workers. I fool myself in thinking that a workflow engine is the panacea when deciding when and what form to present the user.

Workflows are supposed to be adaptable, the forms at the emerged tips even more so. “Can you add a text field here ?”.

In workflow technology, there seems to be this grail where the business user is knowledgeable enough to modify a process definition, and knowledgeable enough to modify a form. Defining a process has a strong taste of programming, and form building hints at hierarchical data structures. It’s a struggle to get right either of them.

I came up with a javascript library named quaderno that takes as input a form template written in a DSL (minilanguage is perhaps a better appellation) and a data dictionary, renders the form, and then, when the user is done, produces the updated data dictionary.

This template :

  tab "general"
    text_input name
    text_input age
    select gender [male, female]
  tab "appointments"
    box appointments.*^
      date .date
      text_input .goal
      text_area .comment

Will produce a form that looks like :

The second tab is gathering data in an “appointments” array. The suffix .*^ indicates that elements of the array, can be added and removed (+ and – merged into a *) and reordered at will (^).

This is a sample output, once the user has entered his values and the produce() function of quaderno somehow got called :

{ "name": "Toto",
  "age": "33",
  "gender": "male",
  "appointments": [
    { "date":"2010/9/18", 
      "goal":"general checkup", 
      "comment": "(and tell him to quit smoking)" } ] }

This example is visible at, there is also another sample at

I use quaderno for highly adaptable forms, whether they are part of a workflow or not. Perhaps I should not say “adaptable”, but “I trust other people enough to let them modify the forms”.

(at first, I had wanted to have three modes, form use, form view and form edit, but the last mode was a bit hard to maintain and the result was awful to use and to look at. I had come up with something better in terms of edition with the initial version, but I couldn’t get to show the link between data and fields. This 3rd version of quaderno is a back to the basics version, with this tiny DSL that moves away from WYSIWYG and exposes the data/form structure)

Quaderno is a MIT licensed javascript library. It’s not a solution, it’s a tool.


Written by John Mettraux

September 22, 2010 at 5:28 am

Posted in dsl, javascript, ruote, workflow

4 Responses

Subscribe to comments with RSS.

  1. This looks great.

    1. Are there any onChange hooks to monitor for user input to do: validation, or auto submission (calls to produce)?
    2. And also to enable, or disable, parts of the form based on user input? (either by recreating the entire form, or parts of it?)

    Use case Example:
    Medical input. Different input fields may be displayed based on gender.


    September 22, 2010 at 6:15 am

    • Hello Benjamin,


      About validation, I go with custom types (for example date_ym) with their own validations.

      You can add custom types by binding their in Quaderno.renderers (documentation coming up).

      Your auto produce idea is great, I will add it.


      Never had this case, but it makes total sense. I guess I’d go with a main quaderno and a ‘related’ quaderno updated depending on the main quaderno (that presupposes your hook idea). Now to make this work ‘inside’ a single quaderno, not sure how I would make it look like DSL-wise.

      Many thanks !

      John Mettraux

      September 22, 2010 at 6:23 am

      • Thanks John,

        The auto-produce hook looks like the right solution.

        And it definitely looks manageable to have related quadernos for such dependencies.


        September 22, 2010 at 7:39 pm

  2. Thanks John. For the benefit of yor readers who may be considering quaderno, I’m happy to say we use it as part of a larger workflow application. The adaptiveness you mention is precisely the value proposition stakeholders have mentioned. Form changes without the need for programmer intervention.


    September 22, 2010 at 6:46 am

Comments are closed.

%d bloggers like this: