To use wdbi to access a specific form you start your WWW-browser with a URL of the form :
http://server/cgi-bin/wdb/database/form-name/mode/keys
Where ...
See below for details.
Three modes: form, query, and default are used to select data from a database and display it to the user. Database queries are 90% of the capability needed from the WWW. The following three sections detail how to query a database using WDBI.
In form mode WDBI reads the form definition file and creates an HTML form in which the user can enter qualifiers. This is the normal use of WDBI. For an example you can try the ESO Telescope Schedule Report located at
http://arch-http.hq.eso.org/cgi-bin/wdbi/eso/sched_rep/form
Form mode is invoked with the form or query_form action.
This mode is used by WDBI internally as the action script to activate when the user presses Search in the query form. However you can also use this mode to ask WDBI to search for something in the database an present it according to the FDF specified. If one row is returned it will be displayed in full-screen output mode, otherwise the tabular output mode is used.
Query mode is invoked with the query action.
There are are two methods you can use to specify what to search for. The first and most used is to specify the key(s) for the table(s) in the FDF. Which fields in the FDF that are the keys is specified with the field attribute 'key' on one or more fields. To access a specific row via these keys you have to add the key values to the URL. If there are more than one key you have to specify the values in the same order as the key fields in the FDF, separated with a double colon ( :: ). Please note that this is the raw database values ( i.e. the to_db function is not used ).
The normal use of this is from an FDF file to provide hypertext links from one database row to another using the 'url' attribute. In fact you will need to use this in every FDF you write to provide access from the tabular output to the full-screen output. For example :
FIELD = more
label = More
type = char
length = 4
from_db= "MORE"
url = "$WDBI/mydb/$form{'NAME'}/query/$val{'key1'}::$val{'key2'}"
computed
forcetab
no_query
no_full
This will create a hypertext link labeled 'MORE' in the tabular output which when activated will start WDBI again using the same form, but this time searching on the two columns key1 and key2. Assuming these two columns together form the unique key on this form, this will lead to the full-screen output of the current row in the tabular output.
mkfdf will automatically add a field like the one above to your FDF files but you might want to modify it, or add url tags to other fields to create links from one form to another.
You can also create URL's to search on something different than the key values. To do this you have to use the HTTP GET method. The general syntax is :
http://server/cgi-bin/wdbi/database/ form-name/query?fieldname=query& fieldname=query ...
Where fieldname is the name of a field in the form, and query is a query on that field as if the user had typed it in. This means you can use operators (like > and < ) and the values will be passed through the functions in the to_db attributes.
The default mode can be used to execute a default query. This is normally used in conjunction with the default field attribute in the FDF. The values in the 'default' field attributes are used as query constraints and the result shown in tabular output format. This is especially useful when the default attributes are expression that depends on the current time, or other external factors.
For example, lets say you have a table with schedule information. The table has a field called start_time with a default attribute like this
default = ">= `date +'%Y.%m.%d'`"
Now you can create a link like 'click here to see schedule starting from today' using the default method.
For example to see the ESO telescope allocation schedule, starting from today, you can use :
http://arch-http.hq.eso.org/cgi-bin/wdb/eso/sched_rep/default
As you can see, default mode is invoked with the default action.
WDBI allows you to insert information into a database via the WWW. Inserts are harder to do than simple queries, but WBD makes an effort to support most simple database structures. WDBI can insert data across table joins, but only uder certain conditions.
If one table contains a key field that uniquely identifies a record, and that field is referred to by other tables, the key field must appear before any other key fields in the FDF. The value inserted into the first table can also inserted into the other tables as the value of the foreign key fields if the dependant fields are labeled in the FDF with the foreign_key tag.
Also, if the unique key is a serial field, which means a unique value is generated for the record before or after the value is inserted, the serial field must be designated in the FDF with the serial_key attribute. Some databases don't support serial fields natively and a simple method is suggested in the DBI file for your particular database. Others do, and WDBI attempts to support these native methods as well.
Under default operations, inserts are not allowed. To enable inserts for a specified FDF, do the following:
mysqlfdf -d dbname -t tablename -o insert (for MySQL) msql2fdf -d dbname -t tablename -o insert (for mSQL 2)Use the version of mkfdf that matches your database. Using the -o option will add all of the necessary fields and headers to your FDF to allow it to be used to perform inserts.
Inserts across table joins currently only works under the following conditions:
The insert_form mode generates a form based on the specified FDF for you to enter data into. You can specify required fields using the non_null attribute so WDBI will not attempt to perform an insert if any required field is empty, and WDBI will return a list of the fields that are required but empty so the user can quickly enter the required information.
In addition, a field can be designated as a serial key so the value generated by the database is inserted into the serial_key field instead of requiring the user to enter a value, plus all foreign keys get the same value.
Instructing WDBI to generate an insert form is done with the insert_form action like so:
http://www.some.where/cgi-bin/wdbi.cgi/database/fdf/insert_form
This mode is used to actually insert into the database the information entered in the insert_form mode.
Instructing WDBI to insert data is done with the insert action like so:
http://www.some.where/cgi-bin/wdbi.cgi/database/fdf/insert
WDBI does updates in a very straight-forward manner. First, you run a query to find the data you might want to update. From the displayed results, you select a record and that takes you to a Web form that is filled in with the data you want to update. When done, you push a button and the data in the database is replaced with what you added or deleted from the Web form.
A copy of the previous values is kept by WDBI so when a user attempts to update a record, WDBI makes sure the record hasn't already been changed. If it has, WDBI prints an error message informing the user of this and tells them how to make their updates. You can turn this behavior off completely by setting ALLOW_UPDATE = no_check in the FDF, or you can turn off checking on a field-by-field basis with the no_where and no_old field attributes.
Some fields, such as primary key fields, should not allow updates by the user. Fields such as these can be designated using the no_update attribute. However, those protected fields are included as hidden form fields so their value doesn't change during an update.
Under default operations, updates are not allowed. To enable updates for a specified FDF, do the following:
mysqlfdf -d dbname -t tablename -o update (for MySQL) msql2fdf -d dbname -t tablename -o update (for mSQL 2)Use the version of mkfdf that matches your database. Using the -o option will add all of the necessary fields and headers to your FDF to allow it to be used to perform updates.
The logical flow from one update mode to the next is like this:
Query Form -> Query -> Update Form -> UpdateThis sequence is explained more fully in the following sections.
This mode is used to generate the initial query form used to locate the data which is to be updated. This is the same form used in the form or query_form (same as form) modes.
This mode is used to perform a database query based on parameters entered by the user in the query form. The results of a query are always displayed in tabular output format with an Update hyperlink for each record. You will select the specific record to update from the displayed results by clicking on the hyperlink.
Instructing WDBI to perform an update query is done with the query action like so:
http://www.some.where/cgi-bin/wdbi.cgi/database/fdf/query
Once you have selected the specific record to update by clicking on the Update hyperlink, your Web browser will display a Web form on which the form elements are filled with the selected data. On this update form, you can add to, change, or delete individual fields. Pressing the Update button sends the changes to WDBI for processing.
Note: if you don't like the word Update taking up space on your output page, you can always edit the FDF and choose a word or letter you like better.
Instructing WDBI to generate an update form is done with the update_form action like so:
http://www.some.where/cgi-bin/wdbi.cgi/database/fdf/update_form
This mode actually performs the action of updating the information in the database. If the record does not exist (maybe it was deleted out from under you), you will get an error message.
Instructing WDBI to perform an update is done with the update action like so:
http://www.some.where/cgi-bin/wdbi.cgi/database/fdf/update
WDBI deletes records from a database using much the same process as updating database records. First, you run a query to find the data you might want to delete. From the displayed results, you select a record and that takes you to a Web form that is filled in with the data you want to delete. Once you have verified the selected record is the one you want to delete, you push a button and the data is removed from the database.
A copy of the previous values is kept by WDBI so when a user attempts to delete a record, WDBI makes sure the record hasn't been changed. If it has, WDBI prints an error message informing the user of this and tells them how to see the new data. You can turn this behavior off completely by setting ALLOW_DELETE = no_check in the FDF, or you can turn off checking on a field-by-field basis with the no_where and no_old field attributes.
Under default operations, deletes are not allowed. To enable deletes for a specified FDF, do the following:
mysqlfdf -d dbname -t tablename -o delete (for MySQL) msql2fdf -d dbname -t tablename -o delete (for mSQL 2)Use the version of mkfdf that matches your database. Using the -o option will add all of the necessary fields and headers to your FDF to allow it to be used to perform deletes.
The logical flow from one update mode to the next is like this:
Query Form -> Query -> Delete Form -> DeleteThis sequence is explained more fully in the following sections.
This mode is used to generate the initial query form used to locate the data which is to be deleted. This is the same form used in the form or query_form (same as form) modes.
Instructing WDBI to generate a delete query form is done with the query_form action like so:
http://www.some.where/cgi-bin/wdbi.cgi/database/fdf/query_form
This mode is used to perform a database query based on parameters entered by the user in the query form. The results of a query are always displayed in tabular output format with a Delete hyperlink for each record. You will select the specific record to delete from the displayed results by clicking on the hyperlink.
Instructing WDBI to perform a query is done with the query action like so:
http://www.some.where/cgi-bin/wdbi.cgi/database/fdf/query
Once you have selected the specific record to delete by clicking on the Delete hyperlink, your Web browser will display a Web form on which the form elements are filled with the selected data. On this delete form, you can verify that this is the data you want to delete. Pressing the Delete button sends the delete request to WDBI for processing.
Note: if you don't like the word Delete taking up space on your output page, you can always edit the FDF and choose a word or letter you like better.
Instructing WDBI to generate a delete form is done with the delete_form action like so:
http://www.some.where/cgi-bin/wdbi.cgi/database/fdf/delete_form
This mode actually performs the action of deleting the information from the database. If the record does not exist (maybe it was deleted out from under you), this is not considered an error. (You wanted the record gone, right? Well, it's gone!)
Instructing WDBI to perform a delete is done with the delete action like so:
http://www.some.where/cgi-bin/wdbi.cgi/database/fdf/delete
Copyright © 1996-98 Bo Frese Rasmussen and Jeff Rowe