How Forms are Published and Rendered

Publishing a Form

Form publishing is complex. Fortunately, iCM does it all for you.

iCM forms are defined by "Object Type Definitions". Their fields are the properties of the definition.

A single page form creates a single object type.

A multi-page form creates an object type per page, plus one for the entire form.

If a form uses an external type definition, it doesn't create an object type of its own - it is mapped to an existing object type.

It's the job of the ObjTypeDef Skeletons to generate the JSON held in these object types.

Publishing a form combines your form definition (ie the form you have designed) and the Form Family, into a single object. This allows iCM to remove the skeletons and properties not used by your form, only include the field types you need, remove all of the help text, and perform other optimisations so the form can be efficiently rendered on the site.

Rendering a Form

Published forms are related to articles in iCM so that they can be viewed by visitors to your site. These articles will generally be using the Forms Service template.

The Forms Service template and the Forms Service worker are responsible for form rendering, form submission, action processing, control flow, storage of uploaded files via the File Store worker, and persistent form sessions (stored in the iCM database).

Field HTML Structure

<ol>
    <li id='MINIMALSINGLE_FIELD2_OUTER'>
        Vertical container field type specific JavaScript & HTML
        <ol>
            <li id='MINIMALSINGLE_NAME_OUTER'>
                Text field type specific JavaScript & HTML
            </li>
            <li id='MINIMALSINGLE_EMAIL_OUTER'>
                Text field type specific JavaScript & HTML
            </li>
            <li id='MINIMALSINGLE_DOB_OUTER'>
                Date field type specific JavaScript & HTML
            </li>
        </ol>
    </li>
    <li id='MINIMALSINGLE_DOSUBMIT_OUTER'>
        Submit button field type specific JavaScript & HTML
    </li>
</ol>

The example above shows a form with three input fields in a vertical container and a submit button.

All fields are output as <li> elements. Their ID is the name of the form, the name of the page and the OUTER suffix, all separated by underscores. Everything inside these <li> elements is field type specific. Most fields include JavaScript to register them with the helper library, event handlers, other custom JavaScript code, and then the field HTML itself.

For example, this is the source output for a single text input field called ISSUEID

<li id="SOAPMODULEEXAMPLE_ISSUEID_OUTER">
    <script type="text/javascript">
        /* <![CDATA[ */
        (function(helper) {
            helper.registerInputField({
                fieldID: "SOAPMODULEEXAMPLE_ISSUEID",
                fieldName: "ISSUEID",
                supportErrorDisplay: true,
                supportEvents: true,
                supportShowHide: true,
                supportShowHideHint: true,
                supportUpdateHint: true,
                supportFocus: true,
                supportEnableDisable: true
            });
        })(SOAPMODULEEXAMPLEForm);
        /* ]]> */
    </script>
    <div id="SOAPMODULEEXAMPLE_ISSUEID_OUTERDIV" class="field_number fielddiv_icmltext clear">
        <label for="SOAPMODULEEXAMPLE_ISSUEID" id="SOAPMODULEEXAMPLE_ISSUEIDLABEL">Issue ID<em title="required">*</em> 
        </label>
        <input type="text" name="SOAPMODULEEXAMPLE_ISSUEID" id="SOAPMODULEEXAMPLE_ISSUEID" value="21724" maxlength="20" class="icmltext">
    </div>
</li>