Form components display a record of data, usually for editing. Forms contain field and button components. Field components display individual fields of the data record and buttons perform programmable actions when pressed.
In contrast to HTML forms, RADpage forms can contain various RADpage field components with advanced functionality. Field components usually check and convert the field content and if necessary generate useful messages in case of input errors. RADpage forms are persistent (except for simpleform), that means form fields keep their values through several dialog steps, so errors are displayed correctly.
Forms need to be combined with programs to be useful. Each formbutton needs to be associated with a process routine that is executed when the button is pressed. Typically the action routine reads the data entered in the form and performs the desired action, by performing database statements, by changing form fields, by calling other components methods, etc. Also sessionRedirect can be called to navigate to another page.
A user program can at any time access the content of a form field. Form fields can be read or written. Usually form fields are persistent and change their values only if either the program changes a field or the user enters new data. Form fields are always stored in the internal format, field components automatically perform the necessary conversions.
A form can be disabled. This is useful to display the form data without allowing the user to enter data. Usually, however, enabling and disabling is controlled by a heitml program.
RADpage forms are (an important special case) of RADpage panels. All components that can contain field components are panels; there are display-panels to display data and panels to display data in an editable way. The latter class are the forms and the input/output panels.
When a form is encountered on a page, it is displayed by sending an HTML form to the browser. If the form is displayed the first time, field components use their initial values. Afterwards the form fields keep their values unless changed by program or by user input or by a form reset.
Alternatively, a form can receive a value parameter that must denote a tuple containing all the form fields for display. The form will then use this tuple to store changed field values.
After filling out the form, the user can press a submit button to request an action, e.g. a database query. This is called submitting the form, because it commonly submits the edited data record to the server to perform the action. The actual action is called form processing. If the edited data is invalid, for instance if the user forgot to enter some mandatory data, the form automatically redisplays the current values, and asks the user to correct the mistake.
There are two technical methods to submit a form; they are called get and post. The former is the default and should be used when it makes no difference whether the form is processed once or several times (such actions are said to be idempotent). A database search is a good example. If it does make a difference, as in a form to order things from an online shop, you should use post.
Form Processing and Error Handling
Form processing takes place when the browser submits the form to the server. Processing reads and checks all the data entered and stores it in internal data format. Afterwards, the action associated with the button is executed. Form processing takes place during the initialization phase of the page, i.e. before anything is displayed.
Error handling is crucial. If the user entered wrong data into a field, form processing notices this and redisplays the form with an appropriate error message. The action associated with the button is not executed in case of an error.
Note that this works differently compared to native HTML forms. An HTML form calls a script for form processing (CGI or whatever). The script can display error messages but not redisplay the form with embedded error messages (without explicitly programming a redisplay). From an HTML view, RADpage forms always have an action pointing back to the page containing the form. This is required to redisplay the form in case of an error. If the successuri attribute is given, however, after successful form processing a redirect is performed to display another page.
While filling out the form, the user might want to start over, i.e. discarding his changes by resetting everything to its initial values. This is called resetting the form and is accomplished by pressing a reset button.
Accessing Form and Panel Fields
The following methods to access form fields work for any kind of panel, although they are most important for forms
While the form is in error state, all fields with wrong data can not be accessed by the user program. The form object contains an attribute named ok that can be used to check the current status.
sesform is by far the most important form component. It has all the properties described above.
The sleform component is a stripped down form, that can work without a session. Normally there is no reason to work without sessions except for very high traffic Web site.
A sleform keeps the fields content only as long as the user presses buttons of this form. If the user uses links or means to go to another page the form content is reset to initial values. Fields that are not displayed on the form but contained in the form tuple do not keep their values, unless hidden form fields are used.
Consider a form to display an invoice. Let's say the database contains the relation "invoice" with a field "customerno" that is a unique key for the relation "customer". In plain words: an invoice record simply refers to a customer record instead of repeating the customer data (e.g. name and address) again and again in every invoice.
Remember that a form displays one record of data. But we've got two! Of course we could try to display each record in its own form. But that won't do, because each form would be submitted separately. What we need is a way to nest one `form' into another. However, the inner `form' is not really a form, because form properties like method and enctype are meaningless there.
For this reason, we prefer to introduce the concept of a panel as a component that can contain fields and other panels. Of course, any form is also an input/output panel. But a form is a panel that can be submitted. The outermost input/output panel must be a form, all inner panels must not.
Don't worry if you are a bit confused now; unless you need to nest panels, you can safely substitute form whenever we talk of panels.
Panels that require a session
Panels that work without a session
Each form or panel can display error messages in case the user entered wrong data. Normally the error messages are displayed at the end of the form. Using the panelerrors component the error display can be positioned anywhere else inside the form.
© 1996-2019 H.E.I. All Rights Reserved.