Design Notes

These are notes you can input that help you and other production staff understand your confirmation elements logic and purpose. This text is never used in the live form in any way, it is only for internal development.

Confirmation Condition PHP Code

This field allows you to specify a condition which must be met for the query field to be processed.

The logic takes the form of:

Variable 1 | Condition | Variable 2

For example, let's assume we have a radio item in our form with the Name/Value of opt_1. The radio item has two possible vales, 'Yes' and 'No'. If the value of opt_1 is 'Yes' we want to send an email, if no, we do not.

We would write the Confirmation/Query Conditional PHP Code as such:

#{opt_1} == 'Yes'

In other words, we use the token for our field variable like we would in other property boxes, that is, a pound sign (#) followed by the Name/Value of the field in braces. Recall that at run time this token evaluates to the value set by our forms users, which in this case will be the value of the radio button with the Name/Value of opt_1.

We then set the comparison, in this case out comparison is equal too, denoted with the double == sign. Finally, because we know our radio item is a string value that can be 'Yes' or 'No', we wrap the value we want to check for in single tick marks.

On the raw code side, RackForms wraps the token call in an isset() block, which is further wrapped in the proper PHP if() syntax:

if(isset($_SESSION['qs']["{$_SESSION['entry_key']}"]['opt_1']) && $_SESSION['qs']["{$_SESSION['entry_key']}"]['opt_1'] == 'Yes') { // condition code start

When run, if the users set value for the radio box was 'Yes', we would process this confirmation element.

PDFTK Enabled?

Defaults to Enabled, setting this to Disabled turns the module off.

Existing PDF File Path

In order for the PDFTK module to work, we need to tell it where the PDF file it will populate resides. The most common path will be one level up from the current directory, in the /forms folder of RackForms.

For example:

../Form.pdf

That is, a file called Form.pdf resides one directory up from the current folder, which means rackforms/output/forms.

It is often helpful to use the RackForms Form Wizard module to upload the PDF to create the web form version:

This will ensure the field names match between the web and PDF form.

PDFTK Output Method

When creating a PDF file, we can process the result in two ways:

1. The first and default method is Download Prompt. This will simply prompt users to download the completed PDF file when they reach the submission page.

2. The second method is Email Attachment, and means the file will be emails to the user, if, of course, an email item exists in the form.

Important Processing Considerations

In order to get the best results when using PDFTK, please be sure to follow these guidelines:

Field names in our PDF file should never have spaces or special characters.

Correct:

Incorrect:

Radio and Check box Items Require Special Care

One big difference between a PDF and web form, is the PDF form will often have been designed for print consumption, then converted into an AcroForm. A common area where this can cause issues is with radio and check box items.

Specifically, these items in a PDF form will have their export values in a "options" box in Acrobat:

The trick is, in this example the 'Yes' value is never shown to the user, but will be in the web version of the form. Thus, when importing forms, it will often be necessary to drag such elements around and position them to better fit in the design.

A good rule of thumb then, is to make sure your original PDF form has plenty of room for such adjustments.

It may be necessary to remove elements from the PDF document before converting to web format

The basic idea here is sometimes, particularly when using a PDF original that had complex submission logic and may contain buttons and the like, such items will create a sub-optimum web form experience.

For example, button elements in a PDF form will lead to button web form elements, these items will not be needed, as we will need to add our own submit buttons.

Another common example of unneeded elements are PDF originals that were designed for print use. Such forms often use graphical elements for radio buttons and other form input. The problem with this is RackForms will convert all graphical elements to background images, which means instead of an actual radio item on the web form, we simply have a graphical element of one.

To further compound the issue, such graphical elements were usually designed for ease of use, making them much larger then modern web-based radio items. Thus, our form will now have an HTML radio item, and underneath, an image of a radio item! Such situations are highly undesirable, as they lead to confusion on the users end.

Thus, in all of these cases it will often be required that we use PDF editing software, such as Adobe Acrobat, to manually remove these elements form the PDF form before we attempt a web conversion.