Forms Technical Details and Their Ramifications

Help Page > Forms > Forms Technical Details and Their Ramifications


The following details regarding the DocStar implementation of forms can help form developers achieve greater functionality and performance.

HTML, PDF, and Renderings

Fundamentally, each DocStar form is an HTML document (web page). The various inputs and labels are all HTML elements. This allows them to be viewed and filled in with any browser, and this is what allows them to be formatted and manipulated using CSS and Javascript.

For all operations except Form Edit mode, a PDF file is generated from this HTML. Actually, one PDF is generated for each form part. This PDF is regenerated immediately by DocStar whenever a change to a content field, which appears on the form, occurs. This is true if the change is made in Form Edit mode or anywhere else in DocStar, including via workflow. The exception to this is a completed form; the PDF content ceases to be updated once the form is completed.

Whenever the PDF representation of a form part is changed, the corresponding renderings change, too.

Performance Considerations

Due to the work required to update the PDF representation and renderings, which is performed directly—not through the distributed queue—there can be a noticeable delay when making a minor change to data on a complex form document.

Form and workflow designers can minimize re-rendering time (i.e. improve performance) by following these guidelines:

  • For large, complex forms, separate the form elements into multiple form parts, and avoid including the same field (unless it is unlikely to change) on multiple parts. Thereby, each change will typically affect only one part, and DocStar will only re-render the part(s) affected by the change.
  • Workflows that operate on form data should combine multiple tasks into a single action whenever possible. A save occurs after each action, and each save will re-render affected form parts. In general – not just in Forms – a workflow with fewer/bigger actions is more efficient than one with more/smaller ones; this difference is more significant with forms due to the re-rendering that occurs.

Modifying a Form Template

Form designers may need to consider the impact of modifying a form template when there are already forms based on that template in use.

First, any completed forms are unaffected. Their PDF representation and renderings no longer change.

Also, there is no immediate impact on any uncompleted forms. Their PDF representations and renderings won’t change until (unless) a field that is used on the form is modified. When modified, these documents will be re-rendered using the new form template. Thus, there may be a period of time in which changes to a form template seem to trickle out to active forms, as they are processed.

Finally, Form Edit mode always uses the latest form template to display the form.

Splitting and Merging

Technically, each form part defines a distinct content item. Consequently, a form document may be split between form parts, and each of the resulting documents is itself a form document. Splitting forms is discussed above under Multipart Forms.

In contrast, if one were to split a document within a form part, this would require “bursting” that content item, and thereafter it would no longer be editable as a form.

The order of form parts and non-form content, which has been added to a form document, can be rearranged via the document thumbnails view. Each part will operate normally even though they are no longer in their original order.

It is also possible to merge parts of two different forms into the same document, although this is not a recommended practice. Each form part will operate according to its respective template.

DocStar ECM Help Center
© 2021 Epicor Software Corporation. All Rights Reserved.