When a form is submitted the associated action with email, spawn or store parameter is processed.
An email address may be specified as a VMS username, a DECnet node and username specification or an Internet Mail (SMTP) address. The system on which VWcms is running must support the mail protocol used. The request data is sent as the message body.
The origin address ("From:") optionally can be specified using the origin=.. parameter.
$$FORMemail@example.com$origin=VWcms at WASD$$
Spawned form processing is specified as a DCL procedure located in the site's directory structure and hence only the procedure name needs to be provided. Agent processing is reasonably specialised and reference to the FORM.C module is required.
When a store parameter is processed the form data is appended to a file in the site directory. This file can be accessed using the VWcms management interface or at the VMS command-line. There are two variants to this parameter, one with a name and one without. If a name is not supplied the file storing the form data is determined using the section name containing the form. For example
in the section Building_The_Site/Reader_Form/Form_Processing (this one) is named
The file name is made ODS-2 compliant if required. If a name is specified that is used as the basis
and would become
Form Data Format
Form data can be supplied as plain text, HTML, XML fragment or raw (POSTed body).
When a VWcms form is submitted certain implicit and explicit validations are performed. Mandatory form elements (+) submitted must be present and if not the form is rejected. Radio and check-box selections are compared to values supplied against the corresponding form field names and rejected if not one of those specified. Text and text-area fields have [comment-reject-word] and [comment-reject-string] constraints applied.
Though a difficult issue to address there are some configurable mechanisms available that attempt to minimise the possibility of form submission abuse.