The first step in allowing users to publish articles on your Web server is to create an HTML form in which authors will enter information. Creating HTML forms that allow user input is relatively straightforward and the process is well documented in many places on the Web. The entry form described in this section is what the user will use to publish a new article.
Every form will have "input fields" into which users will enter data, and with NetForms you can use any field type supported in the HTML standard. Each input field, whether it is a single-line text entry field, a check box, or a radio button, will have a "field name" with which it is associated by NetForms. Be sure to name your input fields with names you can easily remember, since you will refer to them by name when you create NetForms FDML documents.
In HTML, what appears on a web page is defined by special sequences of characters called "tags". All HTML tags begin with a less-than character (<) and end with a greater-than character (>). HTML tags contain a command word and may also contain other words, called "attributes," which provide additional information about the command.
An HTML form is defined by a beginning <FORM> tag and an ending </FORM> tag. In between these form tags are various <INPUT> tags which define the look and behavior of the "input fields" in the form.
Every <FORM> tag used with NetForms must have at least two attributes:
To specify NetForms as the application that will "take action" on the input data once it has been transmitted to the server, you must specify an ACTION attribute in the FORM tag. In the ACTION attribute, simply give the URL to the NetForms application, followed by a dollar sign ("$"), followed by the path to the FDML file to be used to process the data. For example:
<FORM ACTION="/NetForms.acgi$/MyFDML.fdml" METHOD=POST>
In this case, the ACTION attribute of the FORM tag tells the server to use the "NetForms.acgi" application (located in the root directory) to process the data using the FDML document named "MyFDML.fdml" (also located in the root directory).
Here, NetForms.acgi is specified with a relative path because it is located on the same server as the form being accessed. In this case, either a relative or an absolute path may be used. If the entry form is on a different Web server, however, then an absolute URL must be used. In either case the path to the FDML file is always relative to the location of the NetForms root folder. The following example uses the same syntax as above but with an absolute path, which would be used if the form were located on another Web server:
<FORM ACTION="http://www.myserver.com/NetForms.acgi$/MyFDML.fdml" METHOD=POST>
If you are using a web server which supports the concept of server-based "actions" and "suffix mappings", you can simplify the ACTION attribute of your FORM tags. Web server "actions" and "suffix mappings" let the server determine automatically which CGI should process form data based on the "suffix" of the file specified in a URL. For example, you could set up the web server so that all files that end with the suffix ".fdml" are to be processed by the NetForms CGI.
WebSTAR was the first Macintosh web server to support this feature. Using the "Auto-Map" menu in NetForms (see the section "Configuring Your Server"), you can have NetForms set up WebSTAR this way automatically.
Once you have set up an "action" and a "suffix mapping" in your web server, the ACTION attribute of the FORM tag can become simply the URL of the FDML file to be processed. For example, the form command above would become:
<FORM ACTION="/MyFDML.fdml" METHOD=POST>
You can also set up WebSTAR yourself to have NetForms process any file you want, automatically. See "Suffix Mappings" in the WebSTAR User's Guide for details.
There are two methods of sending form data from a Web browser to a server: GET and POST. NetForms supports either method.
The GET method encodes the form data and appends it to the URL specified in the ACTION attribute as "search arguments". Search arguments follow a question mark (?) character in the URL received by the server. Because URLs are limited to a length of 1024 characters, including the protocol, server name, file path, and search arguments, this limits the length of data that can be sent using the GET method. Ordinarily, HTML forms use the POST method.
Using the POST method, the encoded form data is sent in the content of the message sent from the browser to the server. All this means is that there is no limit to the length of data you can send using the POST method. However, NetForms has a limit of 32Kb (32,768 characters) of data that can be received using the POST method.
In either case, you must specify the method you want to use in the METHOD attribute of the FORM tag, as in these examples:
<FORM ACTION="/MyFDML.fdml" METHOD=GET>
<FORM ACTION="/MyFDML.fdml" METHOD=POST>
Finally, if you would like only certain users to have the capability to enter articles, you can protect an entry form in several ways. Using Maxum Development's NetCloak, you can hide a link to an entry form, effectively barring the user from submitting data to NetForms. You can also use Maxum's WebLock to password-protect an HTML entry form page. For more information on NetCloak or WebLock, visit "http://:www.maxum.com/." Finally, you can use your Web server's built-in security realm feature to password-protect an entry form. Check your Web server's documentation for details on security realms and password protection.
To allow users to enter data into your form, you will also need some entry fields. There are various types of entry fields, most of which correspond to user-interface elements you are already familiar with from the dialog boxes on your computer.
Every form field tag must include a name attribute. Later, when creating FDML documents, fields must be referred to by name. Other attributes are particular to each field type, such as type, value or size. For most field types the type attribute is required, but others may be optional.
<INPUT TYPE="text" NAME="myText" SIZE="30" MAXLENGTH="30" VALUE="default value">
<INPUT TYPE="password" NAME="mySecret">
<TEXTAREA NAME="myText" ROWS=5 COLS=40>Default Text</TEXTAREA>
The required "value" attribute will be returned as the value of the field if the box is checked, otherwise nothing is returned. If the "checked" attribute is specified, the box will be checked by default.
<INPUT TYPE="checkbox" NAME="myCheck" CHECKED VALUE="box1">
<INPUT TYPE="radio" NAME="myButtons" CHECKED VALUE="button1"> <INPUT TYPE="radio" NAME="myButtons" VALUE="button2">
Displays a radio button into your form. Radio buttons are so named because they operate like the mechanical pushbuttons on old car radios– pushing one button in selects a particular station, and pushing a different button pops out the previous one. Radio buttons are normally used in a group to allow the user to select one and only one of several options.
The required "value" attribute will be returned as the value of the field if that button is selected. If none of the buttons are selected, nothing will be returned. To link several radio buttons, assign the same name but different values. If the "checked" attribute is specified, that button will be selected by default before the user has selected anything.
<SELECT NAME="myPopup"> <OPTION VALUE="1" SELECTED>first <OPTION VALUE="2">second <OPTION VALUE="3">third </SELECT>
Inserts a pop-up selection menu element into your form. Pop-up menus allow the user to select one and only one of several options, listing each option as text. Popup menus function similarly to radio buttons, but appear quite different.
An option which includes "selected" in the "option" tag will be selected by default. A "value" attribute may be specified inside each "option" tag. If a value is specified, the value will be returned when that field is selected. Otherwise, the text listed after the option tag will be returned when that option is selected.
<SELECT MULTIPLE SIZE=3 NAME="myList"> <OPTION VALUE="1" SELECTED>first <OPTION VALUE="2">second <OPTION VALUE="3">third <OPTION VALUE="4">fourth </SELECT>
Adds a scrolling selection list to the form. A scrolling list has a vertical scroll bar, and lists each option allowing the user to scroll through and select one or more items. Just as a pop-up menu is analogous to a group of radio buttons, a scrolling list is analogous to a group of check boxes.
The optional "size" attribute sets the number of items that will be visible at the same time. In most browsers, the scroll bar will not be displayed correctly unless there are at least four items displayed. An option which includes "selected" in the option tag will be selected by default. A "value" attribute may also be specified inside each option tag to insert a value other than the text listed after the option tag.
<INPUT TYPE="hidden" NAME="myInvisible" VALUE="you can't see this!">
Inserts a hidden field into your form. Hidden fields are submitted as part of the form, but the field and the information in it are not displayed by the browser.
Hidden fields are useful for including information in a form that you don't want the user to see, such as the filename from a previous form, or dynamic information inserted by NetCloak. Note that hidden fields are displayed to the user if they use the "View Source" command in the browser, so they should not be used for security or to hide sensitive information.
<INPUT TYPE="submit" NAME="Submit Form">
When the user is done entering information or making selections, they will need a button on the form to click to submit the form for processing. The optional "name" attribute can be used to specify the text on the button.
Copyright © 1996-8 Maxum Development Corporation
820 South Bartlett Road - Suite 104
Streamwood, IL 60107