Building database driven forms FAST in Flash – Flash RAD Framework

Posted on June 4, 2009


For basic database-transactions (reading and storing data) in most cases, code is created manually for each new project and each new form. In the Flash RAD framework I strive to simplify that process as much as possible, so that building fully working data driven forms is a matter of minutes.

The only things you need to define client side are:

  1. The SELECT statement to retrieve the data from- (and store changes to) the database
  2. An exact mapping of each field in the database to each field in the form.  (See the end of this article)

This week I did the first round-trip test with the “Direct Data Mapping” setup of the Flash RAD Framework.

The screenshots below show the three states of the working proof of concept: 1) Start, 2) Items selected, 3) Record selected + subform presented

Picture 44

One of the goals in the Flash RAD Framework, as said at the beginning of this article, is to generalize and reduce many of the steps required to make a proper form. This includes the implementation of all checks, constraints, interactions and interaction models into a single Data and Form Handler engine: based on rule sets.

MS Access

What I like about MS Access is how you can create user interfaces to database systems without one single line of programming. I basically used the same design principles, but with different weapons of choice: CSS stylesheets and XHTML for all field and form definitions and all data bindings and XML to send data to and receive data from the database.

This week (June 1th 2009) I created the first working proof of concept. Currently I am extending the model to cover most of all basics “MS Access has to offer”.

This article describes some of the basic technical principles for data connections in forms used in the framework. How (user) interactions, object initializations and styling are dealt with will be described in another article.

Simplified model of a form

In the image below you see a simplified presentation of the parts that deal with basic data exchange to the server / database.

Picture 39

Presenting data:

  1. Data is retrieved from the server and parsed via a Data Parser
  2. Via Business Logic, the data is formatted
  3. A Data Setter places the parsed and formatted data into form fields.

Posting data:

  1. Data is collected from the Form Fields
  2. The Form Validator checks if the inserted data comlies to the rules bound to the dataset you wish to send:
    1. Are all required fields filled in?
    2. Do the values in form fields comply to the rules set to that field? (For instance: is the inserted e-mail address at least formatted like a valid e-mail address? Is the value of a numeric field indeed a number?)
  3. If present, the Business Logic performs extra actions on the data coming from the Form Fields. These can be checks to other datasources, calculations or extra formatting of data.
  4. The result is parsed to a format the Server will understand and sent to the server.


  1. Are always done when a rule is broken.
  2. Are presented after the user performs an action.
  3. Fit into the flow set by the Interaction Model.

Most of these elements follow a basic flow that hardly differs from one form to another. This means that they can be fit into a more abstract set of classes (programming logic) that deals with these steps and actions.

Further simplification of the model

The model can then be simplified to the following:

Picture 38

There are three items in this model unique per project:

  1. the Business Logic (specific manipulations on data, specific actions to take before posting data to the server)
  2. Rules for actions (a field only accepts numeric data, has to be filled in, contains data that will be formatted according specific rules before presented), interactions (when the user changes data in a field other items will be affected as well) and interaction flows (the order in which things happen, the chain of steps that lead to a next action)
  3. Responses when stuff goes wrong (feedback on errors in user input, feedback when something goes wrong in sending data to or recieving data from the server)

Accessing the database

On the Database/Server side you will find a similar setup, using a Framework to execute queries and (in our case) returning the result set as XML. Posting data to the server will be done using XML as well, plus a SELECT statement to select the record we want to chane (or add) and parsing each node into the dataset provided by the database.

Picture 37

End result: Data Binding = mapping the data to a form

With the frameworks, the intermediate steps between the front end Form Fields and the back end Database Field dissapears. A Form field is “directly linked” to the fields in a record (see image below).

Picture 40

The only things you need to define client side are:

  1. The SELECT statement to retrieve the data from- (and store changes to) the database
  2. An exact mapping of each field in the database to each field in the form. So the field “firstName” in the database HAS to be reflected in the form as “firstName” and not “first_name” or any other variation.

The Framework on the Server Side deals with the data-connections and returns the data as a one-to-one representation of the dataset in XML to the Flash client. Data sent to the server is packaged in XML as well, reflecting the exact fields in the database and combined with the SELECT satement for that one record, is parsed into the recordset and stored into the database. The framework takes care of mapping the dtate from the XML to the Form Fields and deals with collecting all data from the Form Fields to be sent to the server. Using this simple approach, there is no need to write custom script for each table and each object – unless you are going to perform special actions on that data.

Server Side Business logic

When creating more complex applications with internal transactions as a possible result of your actions client side, you simply create new classes to deal with that side of the story in the way you are used to do it.

Abstraction of steps

All steps between retrieving data from the database, presenting that data in form fields and sending the content of form fields back to the database is abstracted. We still use asynchronous calls to load and send the data. The main difference is that all steps in between – including verification and calls to Business Logic – is standardized via interfaces and clear text instructions and rule sets.