phdcc.Data.Form is a DNN 4 module that lets you define a table and generate a form, and then displays the form to the user and stores the results. Results moderation and other admin also happens here.

• Form design user interface for administrators with basic layout options
• Configurable rendering controls for major changes
• Full CSS stylesheet control
• Multi-language support for users
• Full IPortable import/export of form definitions
• Programmer hooks for form events
• To do: import/export of form results

Each form instance asks a user for answers to one or more questions. The questions and answers are stored in DNN database tables managed by phdcc.Data. You can optionally link questions to standard DNN Profile Properties.

Recordset forms	The form results are stored each time anyone fills in the form.
Profile forms	The results are stored as a profile for each user - and can be updated etc. The profile form questions/answers can optionally be linked to standard DNN profile property fields.
Register forms	This will register a user if they are not logged on; otherwise it acts like a profile form. To make this work, various questions must be linked to crucial DNN profile properties.
Email results	When any valid results are entered, they can optionally be emailed to someone.

Getting a user to fill a form in is just the start:

• Non-valid results are stored to make it easier to return to a long form.
• Profile forms show when valid input already received - and provides an amend option
• Optional user logged-on check
• Default values can be picked up from a user's DNN profile
• Growing list of supported question types
• Full validation, eg field length, integer within range, and dependencies on other results
• Profile form results can be moderated or edited, with a comparison with previous approved results

Although the form aims to provide a lot of general purpose functionality out-of-the-box, the result database format is documented fully so that custom code can be written easily.

Each instance of a form module has:

1. A header area for introductory messages, help and control buttons
2. A footer area for the submit button etc
3. One or more groups of questions. Groups provide visual bracketing but are not stored in the results
4. One or more questions in a group of the following types:
   • button
   • captcha
   • checkboxes list
   • country
   • control
   • currency
   • email
   • file (and image)
   • int
   • multilinetext
   • radiobuttons list
   • text
5. If required, a question has various question options
6. If required, a question can have question dependencies
7. A list of all localised text is stored in a separate string table

The module "Edit Form" screen lets you set up a complete form from scratch. This editor is not WYSISYG but does provide access to all form functionality.

You can configure the output format by altering the supplied stylesheet file phdcc_form.css.

Each form group and question is rendered using general-purpose ASCX controls, ie Groups using Group_Standard.ascx and questions using Question_Standard.ascx. For major layout changes, you can copy and make your own group and question controls.

The results are stored in the following tables:

• One result sets row per form submit
• For each result set, one or more results indicating the answer for each question

If a question is linked to a DNN Profile Property, then the property is updated when a fully validated form is submitted.

A key concept to understand early on is that each form and its elements are identified by "string ID names" which YOU must make up, eg:

• You might create a form with id "idSurvey"
• In the survey form, you might have a first group with heading "Who are you"
• In this group, you might call the first text question "idSurveyName"
• If the second question "idSurveySex" is of type radiobuttons then you will need to provide two options, "idSurveySexMale" and "idSurveySexFemale".

If you look at the results tables directly, then you might see the following for one result set of the "idSurvey" form:

• Question idSurveyName has answer 'Chris Cant'
• Question idSurveySex has answer 'idSurveySexMale'

A ID name must not contain spaces and must be no longer than 50 characters. Within a form, the editor stops you from using the same ID name more than once.

Each form has its own set of ID names so different forms can safely have different values for the same ID name.

Separate forms must have different Form ID names to keep the results separate. If you export a form definition from one module instance and import it into another module instance, then the results from the first instance will be visible to the second instance, and vice versa. This approach lets you import new form definitions and move forms around without losing data.

Using "string ID names" to identify the form elements and results is the key to making it possible to localise the form for users. Each ID name has one or more translations stored in the string table for each form.

• If the user is English then the "idSurveySexMale" option is presented as 'Male'; if the user is German then the option is presented as 'Mann'.
• If male is selected as the answer, in both cases the result for question "idSurveySex" is 'idSurveySexMale'

When you use the "Edit Form" screen to design your form, you will make up ID names for each form element. You will assign actual text values to them for the default locale which is English. Having completed the form in English, you can then add a new locale for the form and go through the form, eg filling in all the German string values.

Use questions that have a Linked DNN property referencing the same DNN property. So the answer from one form is stored in the DNN property. When the other form is loaded, a question will get its default value from the same DNN property.