phdcc.Data DNN modules
Powered by FindinSite-MS
phdcc.Data.Form: Overview
phdcc.Data: Overview Examples Getting Started Security Database Versions
phdcc.Data.Form: Form Profile/Register forms Form editing Languages Layout Questions Form hooks Admin
phdcc.Data.View: View  phdcc.Data.List: List phdcc.Data.Search: Search
Last updated: CC 7/11/08
Color coding
Question parameters
Question types
Special question option ids
Question option parameters
Question dependency parameters
ASP.NET control type
Control name
Special string
Linked DNN property
CSS class

phdcc.Data.Form Overview

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.

Good configurability

What information is stored

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.

Full form input and output handling

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

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.

Overview of form layout

phdcc.Data form layout diagram

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.

Overview of form results

The results are stored in the following tables:

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

ID names

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:

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

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.

ID name localisation and translation

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.

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.

Passing answers between forms

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.