Using Multi-Byte Character Sets in PHP (Unicode, UTF-8, etc)
Using PHP pspell Spell Check Functions with a Custom Dictionary
Development Resource Project
A Simple ISAPI Filter for Authentication on IIS
Journal Gallery Calendar
Username
Password
Log in
Microsoft Office Open XML

Development Resource Project

 Thursday, 22 February 07, 10:06 am
Rich
The aim is to provide a resource where developers can go in order to get code for a specific task.

Objectives
  1. To reduce time from design to deployment
  2. to help maintain code quality
  3. to reduce need for maintanence and support
  4. to help ensure code meets specific requirements (including FF support, security, performance)
  5. to facilitate group work through standardization
  6. to grant designers the ability to easily understand the functionality available when they design a site


Possible Solutions

  1. Skeleton in the Library - Skeleton site and DB, complimented by a library which provides additional functionality
  2. Puppet Master - skeleton library and database provide all possible functionality, which is enabled/disabled through config files
  3. Building Blocks - a library provides compatible components; a site is built from 'scratch' by getting all required components from library
1 2 3    Leave Comment

Rich

12:57 pm, Friday, 23 February 07
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
 
 

Rich

3:20 pm, Friday, 23 February 07
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.
 
 

Rich

12:31 pm, Wednesday, 14 March 07

Control Flow
 
 

Rich

12:54 pm, Wednesday, 14 March 07
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).
 
 
1 2 3  Leave Comment
About This Page