setup
setup

pwPage Setup

There are only a couple of executables; the first being pwPage and the second being pwDisplay. You will normally only execute pwPage, which will in turn call pwDisplay. pwDisplay "can" be called by any program capable of passing expected parameters. An example of calling pwDisplay directly is shown towards the bottom of this page.

The way I have engineered pwPage is to create the pwPage.cgi module and then create symbolic links for each page pwPage supports. For example:

ln -s pwPage.cgi example1.cgi

This only consumes perhaps 15 bytes, so thousands of pages could be supported by pwPage with very little overhead in disk space.

This then means that your HTML form action should be something along these lines:

Assuming you can execute CGI's within directories as you choose, and assuming the pwPage directory is at your document root level. Perhaps the more common usage would be action="/cgi-bin/example1.cgi" or something similar.

HTML Forms generally have some sort of submit button and pwPage is no different. However, pwPage makes use of several. These are:

The Select, Insert, Update, Delete and Review values need to be in the cases as shown, as should formAction. Note that some page creation utilities may resist using the same name, in this case "formAction", but if things don't work even though everything seems alright, you'll want to double check to insure nothing was "automatically" changed. If "formAction" has been changed to, i.e., "formAction1", then you should change them back so that they are all "formAction".

And the last thing you'll want to do is to include a hidden review field similar to this:

to indicate which fields are to be shown when you use the Review option, and which should be on the same line verses on separate lines. A comma "," indicates that the following field should be on the same line, while a semi-colon indicates that the next field should appear on the next line. A period ends the series of fields.

I typically use the column name "lastUpdate" as my table timestamp, but that's optional.

My apologies if I've overlooked anything, but I think this about covers everything. If you encounter any difficulties, peruse the pwPage User Forum for possible answers. I'll try to contribute as time allows, but generally speaking, this forum is provided to allow pwPage savy folks to help new users.

IF SOMETHING GOES WRONG

Every effort as been expended to make pwPage as quick to implement and simple to use as possible. However, there is every possibility that there are remaining bugs; especially since the recent port to mySQL. A pwPage User Forum been provided at which experienced pwPage users can assist less experienced users.

Here are several things you can do yourself to determine your difficulty:

pwPage web pages must have the same name as the table they update. For example, if your table name is product, then your HTML page MUST BE product.html.
pwPage Review web pages must have the same name as the table they support with a Review suffix. For example, if your table name is product, then the Review page must be productReview.html.
pwPage web page field names MUST BE EXACTLY the same as your table column names. For example, if your product table has a column named description, then the corresponding field on your pwPage web page must be the same name and in the same upper and/or lower case.

The sequence of the table columns do not have to coincide with those on your pwPage web page, nor do you have to include all of the columns in your web page that are contained within your table. However, you should include all fields which comprise your table's primary key.
pwPage Review web pages MUST CONTAIN the following indicator to show where you wish to insert table columns:
If you do not include the hidden review field mentioned earlier, the only column that will appear on your <your table and page name>Review.html page will be the rowid column.
pwDisplay.cgi must reside within the same directory as pwPage.
EEKim provides a test.cgi utility you can use to display the field names your pwPage web page produces to help you insure that your web page and table column names exactly agree. If they don't, or if your web page does not follow standard rules of HTML, you can expect the unexpected.
Did you change the URL contained within the pwDisplay.c insertPageBaseURL function to a URL appropriate to your domain? Not having done so invites a high probability of inability to resolve locations of pages, images, etc.
When using check boxes; don't set a default. Let pwPage set these values from the contents of your data base tables.
Although pwPage relies very little on HTML syntax, there are several things it does look for as it peruses HTML pages. Generally speaking, you'll want to insure that input field types are defined first and names second. And you'll also want to insure that your friendly editor hasn't inserted a standalone value statement. If everything else appears to be in place, you may be able to resolve your difficulties by comparing your HTML with that provided in pwPage examples.
Speaking from my own experience, the more common problem will be a mismatch between table column and HTML field names which need to be identical to operate correctly. You may be able to isolate problems by executing pwDisplay directly against your HTML form. This is easily done by writing a simple program similar to the following containing data unique to your form. Here is an example in which error messages are sent to your error.html form:

#include <stdio.h>
#include <stdlib.h>

char form[] = {"../pages/error.html"};
char prefix[] = {"errorPrefix=Major Error Happened!"};
char message[] = {"errorMessage=Hit the road Jack...."};
char action[] = {"errorAction=Sell; sell; sell....!"};

void main(void)
{
execl("pwDisplay.cgi", "pwDisplay.cgi", form, prefix, message, action, NULL);

return(0);
}

WARNING

pwPage.c provides a full range of update and inquiry capabilities. Although providing only, for example, Select and Review buttons will deter most users from being able to update table entries, the thoughtful person can see that there are ways to circumvent this limitation and accomplish unlimited updates. Therefore, some form of security is recommended to preclude this possibility. I prefer to merely limit access to sensitive pages, and if public access of table data is required, to create a crippled version of pwPage.c which provides the combination of capabilities you deem appropriate.

Removing Review capability and using a password as a subordinate key affords protection for some applications. This in concert with perhaps .htaccess security may suffice in some instances as well.

[ Home ]

Last modified: September 11, 2000