Cincom

Primer : Forms Using Scriptlets
On the web, forms allow the user to enter information. When the "SUBMIT" button is pressed, that information can get sent to either another page, either to a scriptlet page (ASP model) or to a servlet (J2EE model). In either case, some code must be executed in order to collect that form information.

This lesson describes how to collect form information using the ASP model (SSP).

1. If the Web Toolkit is not already running and your sandbox site not configured, please do so now.

2. The form used in the example below is Form 1


Figure 1. A standard HTML form with typical input types

3. The attributes on the input tag dictate the input type. In this example, in addtion to the input tag, is the set of select and option tags. These tags create a drop-down selection list on an HTML form. Below are a series of snapshots that show how the HTML is rendered by the web browser.

















4. What makes the form "work" is the following line:

<form name="form1" method="post" action="form1.ssp">

On almost any form you will find a RESET button. It is typically put there as a matter of courtesy since it clears the contents of all controls (input types) on a form should the user decide to start all over again entering data. The real fun happens when the SUBMIT button is clicked.

When the SUBMIT button is clicked, the browser sends the contents of the form to the URL specified in the ACTION qualifier of the FORM tag, in our case form1.ssp. The method attribute of "post" will sends the form data to the server in “named pairs” using the name attribute of the elements on the form. Since the action attribute specified an SSP, one would expect it to contain some type of code/logic processing to extract (and potentially do something with) the data that was sent from the form.

5. The way you pull data from an HTML form using a scriptlet page is as follows:



Another intrinsic ASP model object that is delivered with the Web Toolkit is the request object. The method anyFormValueAt: will retrieve the value parameter of the named form element.

6. Below is the contents of form1.ssp. This code would be considered “optimistic” since it assumes that the user of the browser entered something for each form control.

<html>
<body>
<center>
<%
aName := request anyFormValueAt: 'txtName'.
anEmail := request anyFormValueAt: 'txtEmail'.
anExperience := request anyFormValueAt: 'cboST'.
aJavaPreference := request anyFormValueAt: 'optJava'.
%>
Your name is <%= aName printString %>
<br>
Your name is <%= aName %>
<br>
Your email is <%= anEmail %>
<br>
Your Smalltalk expereince is <%= anExperience %> years
<br>
You <%= aJavaPreference %> Java
</center>
</body>
</html>

7. It is best to assume that the user enters nothing all the time in order to “bullet-proof” the code. Here's a better solution.

<html>
<head>
<title>Results From Sample Form</title>
</head>
<body>
<center>
<h2>Results From Sample Form</h2>
<%
aName := request anyFormValueAt: 'txtName'.
anEmail := request anyFormValueAt: 'txtEmail'.
anExperience := request anyFormValueAt: 'cboST'.
aJavaPreference := request anyFormValueAt: 'optJava'.
%>
Your name is <%= aName printString %>
<br>
Your name is <%= aName %>
<br>
Your email is <%= anEmail %>
<br>
Your Smalltalk expereince is <%= anExperience %> years
<br>
You <%= aJavaPreference %> Java
<br>
<%
aList := request anyFormValueAt: 'chkList'.
aList isNil ifTrue: [
%>
We will not add you to our list.
<%
] ifFalse: [
%>
Thanks. We will add you to our list.
<% ]. %>
</center>
</body>
</html>

Check boxes will return a value of “on” if it is checked or “nil” if it is not. Always check for nil on check boxes. The same holds true for radio buttons. If no radio button is selected (although at least one should be), “nil” is returned.

8. Checking for “nil” on text fields will not work – an instance of a non-null string is always returned. You must check a string for its length (size) and assume that if its length is zero, nothing was entered.


Figure 8. A "smart" SSP checking for data entered in a text field

9. You may be wondering, why the names are printed twice (and why one is in quotes and the other one is not).


Figure 9. Standard ASP/J2EE convention

If it seems strange seeing an object “all by itself” (with no message after it), understand that this is a conformance to the ASP/J2EE model; it is not “slip up” in the Smalltalk engine. If you just want to display the value of an object, the Web Toolkit allows you to use the ASP/J2EE standard of just listing the object itself – no need to follow it with a message (such as printString). This situation is rare. In most cases, you will use the object later on for logic processing and the normal Smalltalk syntax will be used.

10. Finally, another word about readability. As you may recall from the lesson on SSP fundamentals, the use of response write: is necessary when you need to insert something into the HTML output buffer while you are still within a code block. It is, however, optional.

The code samples shown below will generate the same exact output streams. The code sample at the top uses 3 sets of percent tags whereas the code sample at the bottom uses just 1 set of percent tags. All those percent tags (which stops and starts the scripting engine) can sometimes be confusing when mixed with standard HTML tags and normal text. Either code will work but which coding style you choose will simply be a matter of personal preference.

Is the code at the top easier to read (therefore debug) than the code at the bottom? You decide.


Figure 10. Another matter of readability.

Summary

When an HTML form sends data to an SSP (Smalltalk Server Paqe), it is sent as a Dictionary that contains a collection of named pairs. The anyFormValueAt: method of the Request object can be used to extract the values of the named pairs identified on the form.