Overview

Overview Of All Parts

This page explains how the forms work, how they save their data, and how the e-mail templates are chosen.

Parts of A Forms-Solution

These are the parts, just so you have an overview:

1. The HTML-Form, which is generated by the Razor-Template - like _Contact Form.cshtml
2. The JavaScripts which do validation and submitting the data with AJAX
3. The "Save-Program" which is a WebAPI call to a script - like /api/FormController.cs
4. The "database" which is where the data is stored, in the default case in 2sxc
5. The "table" which is a list of Content-Items of a certain type, like ContactSimple
6. The mail-templates which generate the customer / owner mails, like /email-templates/_EmailToOwner.cs
7. Multi-language labels, messages and resources - handled in App Resources
8. List of submissions for admin - currently handled by default 2sxc management
9. Export of submissions - currently handled by default 2sxc export
10. Configurations of all this
    1. Global settings like default sender-mail, Recaptcha key, etc. - handled in App Settings
    2. What Happens On Submit-configurations, stored in a SubmitType (see more below).

Understanding Forms Configuration By Default

Basically you can connect your forms, save/send-webapis and mail-templates any how you want. To save time though, you could stick to the default setup we have in place, which works as follows:

1. The default Web-API saves data to ANY content-type in your app and sends various mails based on configuration
2. The default JS implementation attaches a save-event, does Recaptcha and Validation checks and sends to this WebAPI
3. The default Recaptcha implementation handles Recaptcha for the current area (and skips recaptchas of other forms)
4. The default list-items button opens the list-dialog for a specified content-type and passes a filter for "ModuleId = current module-id"

Configuring Which Parts Go Together

Keeping this all together (in the default setup) is a configuration-item called SubmitType. This keeps track of:

1. Which content-type should be created
2. The file name of the customer-mail templates
3. The file name of the owner-mail template
4. Which Web-API should be called (which then creates the item and sends the mails)

Note that there is a default SubmitType configured in the App Settings. If the default WebApi is called and it doesn't find any special configuration, it uses the one in App Settings.

Note that you don't have to use this SubmitType if you have your own WebApi and just want to save all the settings into your code, like the mail-file names. This is just how we like it, but you're free to do it differently.

Telling a Form Which Configuration To Use

Again you can do everything differently, but here's how we recommend the setup.

• All our (default) forms have a FormInstanceConfiguration Content-Item, which lets the normal editor change the subject line, the send-to address and a few more things.
• All our forms have a Presentation Configuration pointing to a SubmitTypePicker. This let's each form have it's predefined SubmitType-configuration, but allows the advanced user to choose a different one, for example a "Save but Use other Mail Templates" config.
  Note that this is handled in the Presentation, because it won't be changed in 99% of all cases, and using the presentation allows us to centralize the default setting for each form

Whenever you create a new form, we recommend that you also use the FormInstanceConfiguration and the SubmitTypePicker to configure it. You can create your own config concepts, but then you will usually also need to create a custom WebApi or something similar, which would use the settings you added.

Configuration - Defaults and Overrides

There are 3 places a SubmitType can be set:

• At instance-level (like per-module)
• if it's not set, it uses the default of Template-Configuration of that instance - in the Default Item of the Presentation
• and if it doesn't have that, it uses the default set in the App-Settings