|
Webster+ Application Design |
Within Webster+, the application starts upon receipt of a URL request from a browser. The URL will cause the webster.pxp program to be run and may contain the name of an HTML page (pg$=xxx) to load or program to run (tx$=xxx), along with various other application specific parameters.
Any program or page referenced in the URL that starts with an * (asterisk) indicates that the request is for a Webster+ utility program/page. The system will therefore look for that program/page in the *webster directory.
If neither a page nor a program is specified, the system will load the page *default.
The response to an initial request must be an HTML page. If the initial request was for a page, then the specified page will be run through the Webster+ page binding logic. The value specified in the pg$= parameter should be the name of an HTML or plain text file. If there is no suffix on the name supplied, the suffix ".html" will be applied (thus pg$=page1 becomes file page1.html). If desired, you can supply a simple text file with no HTML, only text and short codes; the Webster+ bind logic will convert this into an HTML file.
If the initial request indicated a program was to run, the program must define the pathname to the HTML to generate and place it in %Webster'BindFile$.
The page should contain input fields, buttons, or menu items that either accept/display values or provide a way to send 'events' to the applications. Input fields, such as standard inputs, check boxes, radio buttons or lists, will have their respective values returned to the application. These, along with button and menu items, can have events associated with them.
These events will be received by the program identified in the HTML panels [form xxx] short code. When an event is triggered, the event name will be passed to the program in the variable _event$.
Once the initial page has been sent, the application can, upon receipt of an event, regenerate and resend the page, send a different page, or update values on the page.
If the application code does nothing other than EXIT, the same page is regenerated and sent. If desired, the application can set the %Webster'BindFile$ to a new page and it will be sent. To update fields on the page, the application can call %Webster'Update( ) with the name of the field/fields to update and their values.
A number of Update routines are available that allow updating a single field, a list of fields specified in an IOList, or replace a complete field such as a list box or grid.
Example:
Below is an example of a simple Webster+ page:
<!DOCTYPE html>
<html>
<head>
</head>
<body>
[ttl]Client File[/ttl]
<hr>
[form program=MyProg]
<table width="500">
<tr>
<td>Client ID:<td>
<td>[input ClientID$ format="000000" tip="Enter Client #" event=FindClient]</td>
</tr>
<tr>
<td>Name:<td>
<td>[input Name$ len=30]</td>
</tr>
<tr>
<td>Address:<td>
<td>[input Address$ len=30]</td>
</tr>
<tr>
<td>Address:<td>
<td>[input City$ len=30]</td>
</tr>
<tr>
<td>Balance:<td>
<td>[input Balance format="-###,##0.00"]</td>
</tr>
</table><hr>
[button event=Save text="Save"] [button event=Delete text="Delete"]
[/form]
</body>
</html>
The above code would generate a page similar to this:
From the application perspective, whenever something was entered into the ClientID$ field, Webster+ would run the program "MyProg" and pass in the event "FindClient" in the variable _event$, along with all the data from the form. Selecting Save or Delete would generate their respective events.
In addition to the _event$ variable, the following variables would also be present:
|
|
_changed$ |
Name of variable that changed and caused event ("Custid$") |
|
|
_prog$ |
Name of program ("MyProg") |
|
|
_topmenu$ |
Top menu to display (used by default Webster+ template) |
Webster+ Setup and Configuration