Coding HTML forms for entering, querying, updating and deleting database records can be tedious work, so now ReFORM™ does all of that for you! All you have to do is create the database tables for your application in MySQL (or any other database accessible by Perl DBI modules), and ReFORM™ can generate all of the standard HTML forms you’ll need. Once ReFORM™ has defined a default form for your table, you can change the position, size, labeling and input tag types for any of the fields in ReFORM™’s visual (wysiwyg) design mode.

It doesn’t matter if your table is used for tracking people, companies, donor contributions, customers, volunteer skills, library books, ballot initiatives, water quality test results, calendar events, wildflower species, motor vehicles, housing, congressional voting records, interest group messages, products, e-mail lists, to-do tasks or anything else! If you can define a table that contains the information fields you’re interested in (plus three fields used by ReFORM™ internally for accountability), ReFORM™ will generate all the standard transaction HTML forms you need.

ReFORM™ also includes precise security capabilities for authenticating users by password, managing user-class permissions and controlling individual subscriptions to user-classes that allow them to access, enter, update or delete only the information you want them to.

ReFORM™ supports six different HTML-database form modes. Each of the modes has a different page background color to help users remember what they’re doing and what functions are available at each step.

• New Record Entry/ Input/ Insert form (green)
• Database Query/ Search form (yellow)
• Existing Single Record Retrieve/ Review form (parchment)
• Existing Multiple Record Retrieve/ Review form (parchment)
• Record Edit/ Update form (white)
• Form Design (blue)

Each mode has a fixed set of function buttons. The modes and the function buttons available in each mode are the same for every table that ReFORM accesses. Only the rows of fields and their labels above the row of function buttons change from table to table. The following sections show each of the above modes for a single "person" table that is used to track contact information about individual people. Don’t be misled into thinking that ReFORM only works for address books or that this is the only set of address book fields that can be supported by ReFORM™! We repeat: you can use ReFORM to create re-usable forms for any kind of object that you can describe with a record in a relational database table.

The check box for "Debug Mode" can be used to capture more information if you experience a bug in the ReFORM™ system. The "Debug Mode" check box appears in all modes and stays on (or off) screen after screen until you change it.

The "Max Result Set Size" selector controls the maximum number of records to return for the query for what will become the "current working set" in Review mode. Once in Review mode, you can navigate through the entire result set of the query, looking at one group of N records at a time where N is the number selected with the "Max Result Set Size" selector.

To limit your query you can type any literal value into any field or make a selector or radio button choice (future versions will permit OR-ing of multiple selector values). You can also enter SQL where clause expression into text items. For example:

All Query constraints are cumulative and are ANDed together.

All fields are "grayed-out" because you’re not allowed to change records in Review/Retrieve mode.

The text line just above the function buttons tells you which record of the current working set you are looking at (1), how many records are in the current working set (5), which records are in the current working set (1-5) and the total number of records in the full result set (if there was to Max Result Set Size limit) (1-5). The second "1-5" should just be "5" actually, the first number is always one. The first "1-5" could have been "6-10" or "11-15" or "16-20" if there were more records in the full result set and you were navigating through subsequent current working sets.

The Review-Multiple mode is essentially the same as the Review-Single mode, except that it displays all of the rows in the current working set simultaneously.

The "current" record is the one highlighted in yellow. It is the current record that the "Delete", "Edit", "View 1", previous record ("<") and next record (">") functions all key off of.

Where selectors are ordinarily used to define fields, the underlying stored values are exposed, as in the "Record owner ID" column for example. This is faster and simpler, but might be confusing if there’s not enough literal text stored in the database records. If you get "lost", just switch back to "View 1" mode and get your bearings.

The blue "circle-slash" symbols indicate null (blank) values in the underlying table.

The function buttons in Review-Multiple mode are the same as in Review-Single mode, except that you’ll never use the first record ("|<<"), last record (">>|"), previous record ("<"), next record (">") or "Edit" buttons once you find out that:

1. You can single-mouse-click on any row to make that row the current (yellow-highlighted) row.
2. You can double-mouse-click on any row to bring that row up in Edit mode.

Change anything you want. The changes aren’t saved until you click on "Save" or "Save and Quit".

ReFORM™ users are authenticated with a simple User name and password. The login process stores the User’s ID, name and an encrypted key specific to the particular user, session start time, and session IP address. The key remains effective for two hours after which time the user needs to login again and generate a new key. The user’s password is not stored anywhere on the server, so even if the server were to be "hacked", the passwords could not be obtained.

The key is checked to be valid before each server-side process is run.

In addition to handling user authentication, ReFORM™ has the ability to control which users have permissions to access or modify data on two levels.

Each user may belong to one or more user classes. A user’s membership in each user class is time dependent so that membership may be sold or assigned on a subscription basis and each subscription will automatically time out if it isn’t renewed.

Each User class that the user belongs to causes a new section to appear on his or her main menu. The section includes names of processes that the user can run alongside descriptions of what each process does. Authorization to run a given process is the first level of permission control for a user class. Also included in the menu section is a list of tables that the user can access. Clicking on any table name in the list launches a ReFORM™ screen for that table. User class permissions for table access form the second level of permission control for a user class.

The ReFORM™ system offers a unique way to rapidly develop new web applications and to re-engineer old web applications to make them more easily maintainable and/or less dependent upon commercial proprietary software. ReFORM™ is well-suited to support most organizations’ internal applications whether they are deployed as part of the "intranet" or made available remotely and protected by ReFORM™ user authentication. Because, ReFORM™ relies upon up-to-date browsers (IE or Netscape >= 6.0), publicly accessible internet applications will take longer to support to give browser technology time to spread through the online user community.

====

Copyright (c) 2003 The Bot Works, Inc. All Rights Reserved.