HQ Vancouver is a company that aims to bring in more corporate and international firms to Vancouver, BC. I was the main developer in charge of creating their "What's Your HQ?" registration questionnaire during my employment at Burst! Creative Group Inc. The registration system is built on Drupal 7 using the Profiles2 module.
Client-side Form Validation
Every field on the registration form is required. The form is long, consisting of multiple questions for numerous sections.
One of the problems that came up was that the user would miss a field and continue through the form. Drupal provides form validation but it runs only after form submission. The error messages were not very intuitive and the user was forced to scroll through the form attempting to find the missing question.
We implemented multiple solutions to this problem. The first was immediate client-side validation whenever a change is made to an input. This would check whether the updated field is empty, or in the case of checkboxes, if the number selected exceeds the maximum number of choices. This allows the user to easily see and correct their inputs.
Another solution we implemented was a lock to all the sections until the previous section had been correctly filled out. This prevents the user from scrolling too far down the form and getting confused at the bottom when it says that the form is incomplete. Programming this feature required me to create a nested array of sections and questions. On every input change, I would loop through and validate all the questions in that section to determine if the next section should be displayed.
Server-side Form Validation
In addition to the client-side validation which could check for empty or over-limit issues, there was one field that required server validation; the email.
The registration form creates actual users in Drupal, and the email field has to be unique. Drupal provides default validation for emails, but since the email field was at the top, the user would have to go through the entire form before realizing their email couldn't be used.
I realized soon after that while the module worked, it broke the scroll lock functionality previously programmed. Since the client-side checks were synchronous and the server-side validation was asynchronous, the section validation would skip over this duplicate email check. The section validation would run before the email validation would complete with a response.
In the end, I paused the section validation function on the client-side when dealing with the email field and ran it as a callback on the after the server validation was complete.
After submitting the registration form, the user goes to a review page with all the information previously entered. Creating this page created multiple challenges.
By default, Drupal doesn't allow forms to be split up across multiple pages. We tried to allow the submission to happen and create a user before displaying their own information back on this page. We quickly realized that "officially" the user did not completed their registration. If they left at this point and came back later to restart the registration process, the system would inform them they already had registered.
Our final solution was to create temporary users that were assigned random email addresses. After the user reviews their profile and submits, the system would update their email. They were also marked, so administrators could periodically delete the incomplete profiles from the system.
Dynamically generated PDF
Upon successful registration, an email is sent to the user. This email has a PDF attachment, as well as a link to view it online.
Information on the PDF is based on the answers during registration. Every option correlates to copy that is to be inserted into the PDF so each document is different.
FPDF was used to dynamically generate the PDF. It allowed us to use another PDF as a template for the header and footer so the client had a lot of freedom with the design of the document.