This tutorial is not meant to be a duplicate of the Getting Started tutorial, so we won't go into detail on the different options available in the fields.ini file, I'll just show you the fields.ini file for this form.  It is located in the tables/registrants/fields.ini file.

[first_name]
widget:label = "First name"

[last_name]
widget:label = "Last name"

[school]
widget:label = "If student, School name"
widget:description = "School you are currently attending"

[grade_level]
widget:label = "Grade/Level"
widget:description = "If you are a student, please enter your current grade or level. e.g. Grade 12"

[non_student_type]
widget:label = "Non student?"
widget:description = "Please the option that best describes you."

[non_student_type_other]
widget:label = "Other"
widget:description = "If you selected <em>other</em> in the previous menu, please enter your classification here."

[area_of_interest]
widget:label = "If student, SFU Area of Interest"
widget:type = "select"
vocabulary = "areas_of_interest"

[area_of_interest_other]
widget:label = "Other"
widget:description = "If you selected <em>other</em> in the previous menu, please enter your area of interest here."

[campus_of_interest]
widget:label = "Campus"
widget:description = "Please select your campus of interest"

[registration_date]
widget:type = hidden

A couple of notes...

You'll notice that most of the field definitions are plain-jane with only labels and descriptions defined.  There are a couple of details to notice here, though:

1. The area_of_interest field uses a select widget and uses a vocabulary named areas_of_interest for its options, which is defined in the valuelists.ini file shown below.
   
2. The registration_date field is set to hidden because the user doesn't need to see this field.  It is just a timestamp to mark when the form is submitted.

The valuelists.ini file:

[areas_of_interest]
__sql__ = "select area_id, area_name from areas_of_interest"

The form so far...

At this point the form looks pretty good.  We can go to our application, click "Add New Record", and it gives us this beautiful form.  However it does a little too much.  At this point we haven't added any permissions, so any users can, in addition to adding new records, edit existing records, read all of the records in the system, or even delete records from the database.  This is not good.  From here on out, our task consists of making sure that users can only submit new entries into the form - but administrators can still use the application to review the form submissions.