• Create BookmarkCreate Bookmark
  • Create Note or TagCreate Note or Tag
  • PrintPrint
Share this Page URL

Lesson 15. Building a Web Survey > Assembling the Data in the Survey_P2 Form

Assembling the Data in the Survey_P2 Form

Now that you understand the theory, it's time to put it into practice. In this task, you will work with the survey_p2 form. To save time, I have already created the form and named all of the data—that is, I did to this page what you did for survey_p1 in the previous task. I have not yet done anything to deal with the data issues. You'll have to do that yourself.

Open survey2.cfm.

You'll notice right away that the form is made.

You'll probably also notice a small yellow icon beside each of the questions. This is Dreamweaver's way of showing you hidden fields—they will not show up in the browser. These particular hidden fields actually enable ColdFusion's server-side form validation, a topic that we won't get to until later in this lesson. For now, be aware that the yellow icons are used to store hidden fields; otherwise please disregard them.

Another thing to notice is that the second survey has a different form type than you have used before; it has two text areas where users can enter open-ended comments. These comments work pretty much the same way as radio buttons, text fields, hidden fields, and all other form elements. The element has a name, which is used to match the data to the database table field, and the element has a value, which is written into that field. With text fields and text areas, the user types the values, while with radio buttons, the user's selection is recorded as a numeric value. But the basic process remains the same for all form elements.

Finally, a quick glimpse in the Server Behaviors panel will show that I haven't yet added the Insert Record behavior. You might remember from Lesson 13, when you created registration.cfm, that the Insert Record behavior can be added only once all of the data has been assembled in the form, and at this point, it has not.

Position the insertion point just to the left of the Submit Survey button near the bottom of the form. Using the Forms tab of the Insert panel, add 13 hidden fields to the document.

These fields will hold the 13 pieces of data entered elsewhere (the username, stored as a session variable, as well as the 12 responses entered into survey_p1). At the moment, they don't hold anything. Like any other form element, they need names (to map to database table fields) and values. This time, instead of letting the users enter the values, you will have previously entered values loaded into these fields dynamically. To do that, you will need to make those values available to the document.

In the Bindings panel (Window > Bindings), click the + button, and from the list, choose Form Variable. In the Form Variable dialog box, type q1.

Strictly speaking, this step doesn't do anything to your document. That is, no code is added to the page. What you are doing is defining how variables will be made accessible to the page when browsing the page over a server. While in the authoring environment, the data from survey_p1 and the session variable from the login screen are not available. Until the page is served, that information cannot be made available. What you can do, however, is show Dreamweaver how the information will be made available when the page is served, and what it will be called. In this step, you are telling Dreamweaver that when this page is served, it will have a variable called q1 available to it, and that q1 will be available as a form variable. You are providing Dreamweaver with the details it needs to write code for you that will access these variables, once the page is browsed on a server.

One consequence to this is that there is no way to verify that you are entering correct information. For example, you could tell Dreamweaver that there is a form variable available to this page called bob, and Dreamweaver would dutifully add that variable to this panel and write the code to access it. The code would fail, of course, but Dreamweaver has no way of knowing that. To summarize, the Bindings panel lets you help Dreamweaver write the code to access certain variables, but it is not necessarily a reflection of actual variables available to the page.

Repeat the above step 11 more times, until all 12 form variables appear in the Bindings panel.

Once you complete this step, the Bindings panel contains a complete representation of the data available from survey_p1. Again, the page code hasn't changed, so you'll still need to bind this data to the hidden fields, but you are halfway there.

Before binding this data, let's also specify the session variable data so all the data is available before we start binding it.

Click the + button again, and this time choose Session Variable. In the Session Variable dialog box, type MM_Username.

MM_Username is the name of the session variable created by the Log In User server behavior: Its existence is verified on every page that uses the Restrict Access To Page server behavior. To determine the name, I looked at the ColdFusion code at the top of the page—the code added by the Restrict Access To Page behavior. In line 2 of this page, you will see the following code:

							<cfset MM_Username=Iif(IsDefined("Session.MM_Username"),"Session.MM_Username",DE(""))>


In the middle is a reference to a session variable, Session.MM_Username. Its contents are easy enough to guess. Functions and variables generated by Macromedia behaviors (both server and regular behaviors) are prefaced with MM_. In addition, just as a form variable in ColdFusion is represented as form. followed by the variable name, so a session variable is referenced by session.variablename. For example, q1 would be represented in ColdFusion as form.q1, while a session variable of the same name is session.q1. In both examples, q1 is the name of the variable, while the part that precedes it specifies where the variable is coming from—a form submitted to the current page or a session. Therefore, this session variable's name is MM_Username.

Now all the data originating from elsewhere is assembled. Let's drop it into the survey_p2 form.

Click the first hidden field in the row to the left of the Submit Survey button. With the hidden field selected, click q1 in the Bindings panel. Now click the Bind button at the bottom of the Bindings panel.

With this step, you are dynamically populating the hidden field with whatever data the user entered in the first question of the form. Feedback that the binding was successful appears all over the place. In the code, you'll see that the value of the hidden field has been set as follows: value="<cfoutput>#Form.q1#</cfoutput>">. This tells the server to evaluate the variable Form.q1 and output it as the value of this form field. Thus, if the user entered Strongly Disagree to question 1 so that the value 0 was sent to this page, then ColdFusion replaces <cfoutput>#Form.q1#</cfoutput> with 0. And that 0, ultimately, will end up in the database.

Other signs that the binding was a success appear in the Property inspector, where the hidden field's Value box is set to <cfoutput>#Form.q1#</cfoutput>, which is the GUI [graphical user interface] equivalent of the code described in the previous paragraph. In addition, as long as q1 is selected in the document, the word input.value appears beside it in the Bindings panel, and the Bind button at the bottom has changed to Unbind. It's official: form.q1 and the first invisible field are married.


The order of hidden fields does not matter. They are not visible to the user and are inserted into the database regardless of their placement or organization, as long as they are in the field. Likewise, their exact location between the form tags (here, they are beside the Submit Survey button) doesn't matter, either. The only advantage to doing them in order and keeping them all together is that it decreases the chance that you will make a mistake or forget to bind one to data.

One at a time, bind each of the remaining invisible fields to a data binding in the Bindings panel.

The session variable doesn't require any special treatment. It is bound the same way that the others are bound.

Now the only problem remaining is that these fields don't have meaningful names. Each field is still named by the default hiddenfield1, hiddenfield2, and so on.

One at a time, select each field and enter its name in the Property inspector.

The first one should be named q1, the second q2, and so on, until you get to the hidden field bound to the session variable. Its name should be username. Again, these names all correspond to the fields as they exist in the database, which makes matching the form elements to their intended database fields that much easier.

The survey_p2 form is now complete, including data taken from login.cfm, survey1.cfm, and survey2.cfm.

Now would be a good time to save the file, but don't close it just yet.



Not a subscriber?

Start A Free Trial

  • Creative Edge
  • Create BookmarkCreate Bookmark
  • Create Note or TagCreate Note or Tag
  • PrintPrint