[00:00] In this lesson, we'll continue to explore the structure of the form component and learn more about submission management for the sample form we created in a previous lesson. Although our form contains many different widgets in the designer, the form component will collect all the data entered in one place. I'm in preview mode and I've filled in most of the pertinent information within our form. If we go to the Perspective property editor and scroll down a bit, we can actually see that data being collected inside the data object. These are the IDs associated with each widget in our form where data's been entered. The form component uses ID-based organization keyed on what the form designer defines in the widget configurations, and then the form component collects the values in the data object at the root of the project. Each ID should be unique. One other helpful aspect of the form component's design is the built-in form validation and status check. In the property editor, we can take a look at the validation and status objects to see how we're doing with both of those. Here, if we had any problems with our data, we would get warnings for any form values that might be failing validation or values that are missing altogether.

[01:13] All of our data looks fine, so we're in a good place to start submission management setup. Submission management for the form component will also start in the Perspective property editor. I'll head up to actions and check out the submit object, so we can see what options we have built into this component. All these properties have handy tooltips that'll help you navigate through the options if you need clarification, but let's get this form set up and ready to fire a submission event. The submit button is disabled by default in the form component until there's data entered into the form, like in our example. If you'd like to customize the button text, the text property allows you to enter a new string value. I'll just pop in a new value. For our sample report form, I wanna use the fireSubmissionEvent capabilities, so I'll make sure fireComponentEvent is false and set fireSubmissionEvent to true.

[02:05] A new property will appear called submissionHandler. This is where we'll enter the name of our form submission handler script once we've created it. This just tells ignition what action to take when the form is submitted. If you have contingent actions included in your form, as in this example, where our toggle switch value controls the behavior of the checkbox and numeric widgets, these properties will allow you to include disabled or hidden field values in your submission by default. If you'd prefer not to include those values, you can simply set these properties to false as needed. Next, we'll make sure that autoDisable is false. The resetOn property allows you to tailor when the form will reset itself. By default, that value is success, so we'll leave that setting as is. I'll set the awaitResponse value to true, so our form will know to wait for a response, whether that's an error, a partial success, or success. If you have both the fireSubmissionEvent and awaitResponse properties set to true, then the responseDisplay object gives you some additional options for how to display the response, if you'd like to customize the look and feel of the information.

[03:10] With all these settings in place, the fireSubmissionEvent property will help us trigger the built-in submission actions along with a little work we'll do in Gateway Events next. Let's turn off preview mode. I'll head over to the project browser and click to expand Perspective Gateway Events. This gives us access to the form submission handler scripts that run when we initiate a form submission. If I right-click on Form Submission and select New Form Submission Script, we can give it a descriptive name. I'll set it to handleForm. The next window is where we'll write a handleSubmission script that'll fire on click of the submit button. We have access to the session and form information as well as a dictionary with all the form data from the data object we explored earlier. I'll put in a basic test script. This is just a starting point for demonstration purposes, since you can customize the script for submission management in whichever way you choose.

[04:07] Next, I'll return to my form. In the Perspective property editor, I'll pop in the name of our script, handleForm, as the value for the submission handler property. I'll save my project to make sure that the changes are persisted. Now we can launch a Perspective session, open the developer tools, submit our filled out form, and see a success message at the bottom of the screen when the form sends the information and resets. In the console, we see our scripted success message as well. That's really all there is to it. Submission management within the form component is flexible and easy to use. Tailor it to meet your needs with a custom script of your own and let your data do the talking.