www.internetology.co.uk, domain, names, domain, domain registration, web design, online shop, web designer, internet, web, design, e-commerce, graphic design, register, names, email, e-mail, free, creation, DNS, WHOIS, domains, web hosting, ISP, online banking, internetology, manchester, wrexham, chester, cheshire, north west, north wales, england, UK

Internetology - FormPost 2

Key Features
How To use FormPost2
Using FormPost 2 with FrontPage
How to use Hidden Fields in your Forms
How to use Templates in your Forms
Special Form Fields
Form Encryption


Key Features

  • Customisable results file format for saved data on the server.
  • Customisable 'notification' email sent to a single specified email address.
  • Customisable 'confirmation' email sent to either fixed email address, or the address specified by the form user.
  • Customisable page-parser, let's you produce a page including output from previous forms / details (*advanced feature)
  • Supports any mixture of saving the results (i.e. writing them to disk), mailing the results to a fixed address or mailing to a user-defined (by the person filling the form in) address.
  • Can send user to a specific URL once the form has been completed (e.g. "http://www.internetology.co.uk")
  • Can send the user a specific 'confirmation' page, which can include details from the original form they filled in.
  • Provides 'special' fields which can be sent in either the email notification, email confirmation, displayed in the users browser or written to disk with the saved results. These fields include the Date, Time of the submission. A 'unique reference' ID for that submission. The 'host name' of the users machine, as well as all the fields defined in the form.
  • Ability to PGP encrypt form responses, before they're saved to disk - and before the 'notification' email is sent out (which could contain all the posted data). PGP keys have to be pre-registered on the server, and are only available to customers taking out SSL / Secure server setups.
  • Ability to specify 'Mandatory' fields, which must contain data or the form will fail to process. Missing fields can either result in a default "missing fields" page being sent, or a user defined page which can again include data from the original form submission.
  • Ability to create 'world readable' files, which with the use of the output templates, can be in the format of HTML pages, e.g. for a simple message board etc.
    With this flexibility comes some level of complexity, but we've tried to keep things as simple as possible.

*People should generally only use this feature once they are comfortable with the rest of Form Post 2's facilities.

How to use Form Post 2

Simply create a web page, and embed the standard HTML FORM tags, e.g.

<HEAD>
<TITLE>Test Page</TITLE>
<BODY>
<P>This is a test page, please fill out my form.</P>
<FORM ACTION="/aspx-bin/fp2.aspx" METHOD="post" NAME="myform">
<INPUT TYPE="HIDDEN" NAME="DBFILENAME" VALUE="/my_results.txt">
Your Name: <INPUT TYPE="TEXT" NAME="customers_name" LENGTH=80><BR>
Your Telephone: <INPUT TYPE="TEXT" NAME="telephone_number" LENGTH=80><BR>
<INPUT TYPE="SUBMIT" NAME="Submit" VALUE="Submit">
</FORM>

Using Form Post 2 with FrontPage

For Frontpage 2000, you can tell Frontpage to use 'fp2.aspx', by doing the following:

1. Create a form, as you would usually using Frontpage

2. Once the form is complete, right click within the forms bounding box, and pull up the form's properties.

3. Select the "Send to Other" option.

4. Select "Options", put "/aspx-bin/fp2.aspx" into the 'Action' field. Make sure the method is set to "Post" (which is the default), then close this dialog.

5. Click on "Advanced" - this let's you setup 'Hidden Fields' which control the form's behaviour. For example, if you hit 'Add' then enter 'NOTIFYMAILTO' as the Name, and put your email address in as the 'Value', this will result in your email address being emailed every time someone fills out the form. You can keep adding additional fields as and when required to control the form post.

Hidden Fields

Above is the simplest kind of form that will work. It will take input from the user, and save it to disk. It will not email you (i.e. the Webmaster) it will not mail the person using the form, and when it's submitted they will be taken back to your sites main page (which is the default).

The hidden fields are used to tell the form post what to do. The following hidden field names allow you to control how the form post will work:

DBFILENAME - If you set this it is the name of the file to write the results to. The filename has to start with a "/" and will be created in your public-html directory, i.e. outside the directory your pages are in. This ensures you (or others) can't damage your online pages by writing results over the top of them, and it stops people browsing your site from downloading your results files.

CONFIRMMAILTO - The email address of where to send the "confirmation" email. This is typically done as a 'text' form field so that the person using the form can specify where the confirmation mail is to go to. An example of setting it inside the <FORM> </FORM> tags would be:

What is your email address?: <INPUT TYPE="TEXT" NAME="CONFIRMMAILTO" LENGTH=80>
If you do not set this field, or the form user doesn't put anything in it, they will not be sent a confirmation email. In addition to CONFIRMMATILTO you can also use CONFIRMMAILTO2, and CONFIRMMAILTO3 to specify two extra delivery addresses, that will receive a copy of the confirmation email.

NOTIFYMAILTO - The email address of where to send the "notification" email. This is typically a short email to the sites webmaster, to tell them that someone filled in their form. The webmaster would then know to check their servers results file, where the results would hopefully have been saved to. Alternatively the NOTIFYMAILTO address can be sent all the fields from the form (this is controlled using the NOTIFYTEMPLATE setting below). As with CONFIRMMAILTO, you can also set NOTIFYMAILTO2 and NOTIFYMAILTO3 to two additional email addresses, that will receive email notifications when the form is used.

The next two fields are optional. If none are set, then when the form has been processed the user will be sent a simple page, thanking them for filling in the form - and offering a link back to your sites main page.

OKURL - The URL to take the user back to when the form has been processed OK. This should be a proper HTTP style URL, e.g. "http://www.internetology.co.uk/thanks.html".

Or, you can set:

OKPARSEPAGE - To the name of a file that exists under your server. This file will then be 'parsed' to the client. This gives you an opportunity to display a page to the user, and replace parts of the page with either set details from the server (e.g. Date, Time etc.) - or with data they entered in their form. Typically this would be a "confirmation" page, or a page for the user to print and keep. It would also typically have a "Click here to go back to the main site" link at the bottom.

PREPARSEPAGE - This is a special variable. When set, it must point to a filename within your webspace. This file will be 'parsed' and displayed to the user - before any form post actually takes place. This lets you incorporate form fields from previous forms into a new form. It's considered an 'advanced' feature, and should only be used by people who are already comfortable with FP2's existing features.


WORLDREADABLE - If this hidden variable is set to the value "FORCE" the file that the server creates to hold the results, will be created in world-readable format, i.e. the web server will be able to display this result to clients. This is not recommended when you are storing any kind of sensitive information. The default mode is to create files which cannot be read by the web server - this stops people from looking through the source code of your page, and then retrieving your results file directly to their browser. You should fully understand the implications of using world readable files, before using this hidden variable to turn the option on.

Templates

Templates are the key to changing what information the server saves to disk from your forms, what information it sends you - the webmaster, and what information it sends back (as a 'confirmation') to the person who used the form.

Templates work by having 'at codes' in them, which get replaced by the server with either details from the form, or server information such as the Date, Time etc. 'at codes' are very simple. An example 'at code' might be:

@TIME
When the server reads this, it will replace it with the current time, e.g. 22:07

By using this powerful system you can build custom email 'templates' to send to the users, and also control the format of the form post data when it's saved to the servers disk.

For example, an typical confirmation email template might be:

Dear @FIRSTNAME,
Thankyou for using our Website at www.mycompanyname.com to post your comments.
We received your comments at @TIME, on @LONG_DATE. We will hopefully respond within the
next 5 business day.
Regards,
Webmaster
When this is sent after the user has filled in the form, it might come out looking like:

Dear John,
Thankyou for using our Website at www.mycompanyname.com to post your comments.
We received your comments at 22:11, on Wednesday 21st of March, 1999. We will hopefully
respond within the next 5 business days.
There are three different templates that the system uses to control the format of the database, confirmation email and notification email. These are files you create in your webservers directory. You tell the form post script which templates to use by specifying the following hidden fields within your form's <FORM></FORM> tags:

CONFIRMTEMPLATE - The name of the file to use as a template when sending 'confirmation' emails (typically emails sent back to the person using the form).

NOTIFYTEMPLATE - The name of the file to use as a template when sending 'notify' emails (typically sent to the sites webmaster to tell them the form has been used).

DBTEMPLATE - The name of the file to use as a template when saving form post results to disk.

COUNTERFILE - The name of the file on the server to hold your counter reference number (see @COUNTER_REFERENCE). The file will be created if it doesn't exist. You can edit the file, it stores the number as ASCII

If you do not specify a template file (e.g. if you tell the form post to mail a confirmation email back to the form user, without telling it a template file to use) it will use it's own default format. This format is not 'pretty' but does contain all the fields that were filled in on the form that the user submitted.

You can use fields from your form as 'at codes', e.g. if I have the following entry in my form,

Enter your first name: <INPUT TYPE="TEXT" NAME="firstname">

I can then use the 'at-code' below to put whatever the user entered as their 'first name' into any of the template files:

@firstname

*Important Note* The fields and 'at codes' are case sensitive. "@firstname" and "@FIRSTNAME" mean different things to a computer, i.e. it will only find an exact match. Using the above example, "@FIRSTNAME" will just be replaced with empty space, as the server didn't match anything to it.

In addition to the fields you have created in your form, the server also provides the following fields which can be used in templates...

@LONG_DATE - The current date, in "English format", e.g. "Thursday, 23rd September, 1999"

@DATE - The current date, in "short" format, e.g. "23/09/1999"

@TIME - The current time, in "short" format, e.g. "22:01"

@LONG_TIME - The current time, in "long" format, e.g. "07:23 pm"

@UNIQUE_REFERENCE - A 'unique' reference number generated by the server, which can be used to give customers a 'unique' reference number relating to that forms submission. Be careful, if you tell the user their unique reference number - you should also make sure you either mail this to yourself (by putting "@UNIQUE_REFERENCE" into the notify template) - or make sure it's saved to disk, by putting "@UNIQUE_REFERENCE" into the database template. If you don't, and you lose the unique reference number - there is no way of getting it back from the system - it will then be truly 'unique' (unfortunately!)

@COUNTER_REFERENCE - Is replaced by the number from your counter file. To use this you must have set the hidden field "COUNTERFILE". The counter is incremented by 1 when the form is processed. If you use @COUNTER_REFERENCE and have not specified a COUNTERFILE the system will replace @COUNTER_REFERENCE with "" (nothing), and not show an error.

@SERVER_ADMIN - The email address of the servers webmaster. Not very useful, but good if your copying your template between a lot of different servers, and don't want to change the webmasters email address on each template.

@HTTP_USER_AGENT - The name of the browser the form user was running.

@HTTP_REFERER - The URL of the page the user arrived at your form's page from (again, not very useful?)

@SERVER_NAME - The name of your webserver, e.g. "www.internetology.co.uk"

Special Form Fields

The following form fields have 'special' meanings, they can either be set by the form's designer by using HIDDEN fields, or they can be left as standard TEXT fields, allowing the person using the form to change their contents.

NOTIFYSUBJECT - The 'Subject' used in the email to notify typically the webmaster that the form has been used. If not specified this defaults to "re: Form post at [url]" - where URL is replaced by the name of the page that was used to form post from. The subject can use @ codes (e.g. the subject could be "Re. Your Order @UNIQUE_REFERENCE).

CONFIRMSUBJECT - The 'Subject' used in the email sent to the CONFIRMMAILTO address. Again, this defaults to "re: Confirmation of Formpost from [site-name]". Where 'site-name' is replaced by the address of your website. Again, this can use @ codes.

Mandatory Fields
You can force a user to fill in a field, before the form submission is processed. To do this you must prefix the name of the field with a special character. For example, to force the user to supply their "Full Name" you would use:

Enter your Full Name: <INPUT TYPE="TEXT" NAME="R_fullname" LENGTH=80> (* Required)
The "R_" prefix means 'required'. The system will not process the form completely until they have filled in something in this field. If they fail to fill in this field, they will either be shown the page set by the hidden field MISSINGDATAPAGE, or they will be shown a simple "Please check all fields" page, with a link back to the form.

Putting "(* Required)" next to the field is a good idea, it shows the person using the form that they should put something in to fill in this field.

Encryption

Form Post #2 offers the ability to encrypt the form's contents before it's saved to disk, or before the notify email is sent. The contents of the 'Confirmation' email cannot be encrypted, as the form user is unlikely to have the correct PGP software to decrypt it.

To enable encryption you need to set the field:

KEYID - Should be set to the 8 character ID of your PGP key. If this is set the following fields also come into play.

CODEDB - If set to any value, e.g. "YES" means the data is encrypted before being saved on the server.

CODENOTIFY - If set to any value, e.g. "YES" means the notification email is encrypted before being sent.

To use the encryption facility properly you will need a Internetology 'secure server' package, along with an SSL certificate. In addition you will need to register your PGP public key with our server.

Restrictions of Use

Notification / Confirmation emails cannot be over 8k in length.

You can't save Form Post results that are over 8k in size to the server (i.e. by using DBFILENAME etc.)

If your using options such as "OKPARSEPAGE" the page being parsed cannot be over 16k in size.

When using the "COUNTER_REFERENCE" features, the counter file used is readable by the webserver, i.e. someone can view the source of your webpage, get the counter file name - and then ask the browser to display this. This shouldn't be a security risk - but it is something you need to be aware of. The results files saved by the system are not readable by the web server - as the server only needs to write to these.

If your site is extremely busy processing form requests, there is a chance the server will not be able to acquire the 'next' reference number to use for the "@COUNTER_REFERNCE" feature. If this is the case - the form post will return an error, instead of risking issuing the same reference number twice. This should only happen under exceptional circumstances.

If you use an '@' (at) symbol in your templates, e.g. for an email address of "webmaster@somewhere.com" - you will need to use the at symbol twice, i.e. webmaster@@somewhere.com. Using two '@'s causes the system to only display one of them, and not bother trying to look up any values for that field.

All paths specified for templates etc. are relative to your servers root area. This is because path names are not supplied during form post operations, so the program always uses the server root directory. For example, if you keep your "formpost.template" in a directory called "templates", in your hidden fields, the correct path to use would be "/templates/formpost.template".

Copyright © 2007 www.internetology.co.uk : All Rights Reserved
Please read our Disclaimer If you have any questions, please contact us