Menu

How does Forms in the Flow model work?

Forms are the Flow components that cause something else besides progress messages to appear in the UI when the Flow is progressing. Their primary use is to gather input from the user that can affect what kind of document is produced, or perhaps affect the route that the Flow will continue on.

Each Form has a HTML template associated with it. When the Form's turn in the Flow comes up, the HTML template's contents are evaluated and this evaluated result will be the pop-up or changing in the browser's Form presented to the end-users. The Form templates evaluate exactly like the body or email parts in the Online Templates, so all dynamic elements and such work in the same way.

The basics of designing a Form

To obtain input from the user, a Form needs some elements for that purpose. One can use common HTML input elements for this - the value of such an element is automatically delivered to the Flow's variable context when the user leaves the Form, using the element's name as the variable name. So the value of a text input with name testValue could be accessed by following Steps with the expression ${testValue}. The input values appear in the context generally with the types one would expect - text inputs produce strings, file inputs produce files, and so on. Note that if a Form input has the same name as an existing variable in the context, the value from the Form will overwrite the variable's existing value.

For leaving the Form, at least one submit button is needed, as pressing any submit button causes the Form to disappear and the Flow to continue. Set the Next step attribute for a submit button to define where the Flow heads next, or leave it undefined to conclude the Flow's current Segment. Furthermore, setting a name for every submit button is suggested as the name of the pressed button is available within the Flow logic, accessible with the EL expression ${param.button}.

Note:

Please always remember to have at least one submit button on a Form, as otherwise the user will become stuck and is forced to close the Flow.

Editing Form directly in HTML

While Form templates can be edited in the Form editor, editing a Form template's HTML source directly is also very possible. Almost any kind of HTML can serve as a Form, but there are a couple things to take note of:

  • For technical reasons, Form templates need to be valid as XML, which primarily means that all tags must be closed properly. If a Form template fails to be proper XML, the Flow will be interrupted by this error when the related Form comes up.
  • A Form template can be a HTML fragment, like a single <div> with the content inside it, or a complete HTML page with all the structural top-level elements. In the latter case, only the contents of the <body> element will appear as the Form. Not everything outside the body is irrelevant though, as the document head may contain links to resources used by the Form.

CSS in Forms

While all Forms inherit some styling from the UI presenting them, it is not rare for a Form to require its own style rules. For this, a Form may be accompanied by a CSS file residing within the Document application or template. Forms produced with the Flow editor do this automatically and the related stylesheet may be accessed through the editor. How this link between the Form and a CSS file appears in the Form HTML is how such a link appears in any HTML page - a <link> element in the page's head. Like this:

<link rel="stylesheet" type="dynamo/css" href="Main/style.css"/>

The type of the link needs to be "dynamo/css" for it to be recognized as the Form's style, and the href should point to the CSS file within the Document application's archive, or the CSS resource's ID in an Office template.

Comments

0 comments