To start, I have created a very simple directory structure. There are three folders: model, view, and template.

The index.php page is the controller. The template could follow the Joomla concept: a formatted HTML page, with embedded calls to get content eg writeMainBody(), writeLeftNav(), writeFooter(), etc. If we do this, then it is these functions which need to determine the appropriate content for the page, rather than index.php. So, index.php follows this procedure:

1. Get config settings
2. Get input from Request
3. Include relevant Model classes
4. Call Model classes to make any changes to DB
5. Include template
6. Template calls View classes which display appropriate data

I now have a basic structure in place.

A HTTP URL parameter, called view, specifies the content to display on the page. The controller (index.php) sanitizes and stores this parameter in the $view variable.

A PHP class, HTMLComponents, is instantiated. This class is used by the template to place the elements of the page in the appropriate places.

The controller finishes by including the template (template/index.php). As stated, the template contains calls to methods on the HTMLComponents class, such as writeTitle(), writePageNav(), and writeMainBody(). This last takes $view as a parameter, and the function checks for 'modules/'.$view.'.php'. If this file exists, it is included, otherwise we include modules/home.php to generate the default content.

I've spent the last couple of days working on a generic database edit module, for admins. The idea was to create HTML forms dynamically, based on the structure of a specific database table. The form allows the admin to insert / edit rows in that table.

This module works pretty well so far. It handles editing, saving, as well as correctly choosing which type of HTML field to use for each database column. For instance, if the database column is an enum, a select box is created, where each possible value of the enum is a selectable option.

The module gets type information for the database table by running a DESCRIBE tablename query. Additionally, a text file for each form specifies some information that cannot be derived directly from the database. This includes which columns to render as file upload fields, which columns are required, which to render as hidden fields, and which to ignore totally. The text file also allows the user to specify a 'screenname' to use when creating the labels for a field.

I have started implementing more enhanced validation (in addition to required fields), by checking the size of char/varchar fields, and triggering an error if a text field is above that size. This means that if a text field has a maximum size, all that is required is to set the size of the corresponding database column accordingly.

Additional validation of this sort could be implemented for suitable column types, if there are any others. If not, some reliable format for entering validation rules in the text file is needed.

Another feature which is essential for practical applications of this module is FK support. The module must allow certain fields to be FK - ie they refer to another database table, and the form must create a select box using specific columns of that other table for the values and text labels of each option.

There are two possible types of FK relationship: 1 to 1, and 1 to many. The first case is the most straightforward - such relationships are represented by a single column holding the PK of the second table. The second requires a 'middleman' table, which links PK of the first table to PK of the second. Such relationships may require a multiple select box, and typically require another query to be executed to create the relationship (once the PK of any new row is known).