Please note: This is an unpublished site and we are making changes - glitches still!!!

Administration tool basics

Writing an administration tool is a formidable job. We must write modules that read from the database either one record or an array of records, make changes to records, insert new ones and delete unneeded ones. We need views for tabular data from various sources, lots of update forms and the database updating logic.

Moreover, it would be very nice to have a visual tool for creating and editing the pages. We also need a menu editor... the list sounds endless. Sigh.

Do not optimize when it is does not pay off!

There is one thing one should keep in mind and it is not that obvious, really:

While we really need to optimize the key parts of a busy site at the visitor end we can relax while building the administration end. Why? There may be thousands of requests at the public view whereas administrative tasks are done probably on a daily or a weekly basis. Therefore they use a fraction of the system resources the public part does. That does not mean, however, that we can throw all our principles over board. We must write good, maintainable code. Period. What it means that the time spent for optimizing the creation speed of an update form, for instance, is time totally wasted. That lets us concentrate more on the functionality of the administration end.

That said the administration libraries and tools provide very good performance. The statement above is just a counter arguments to variouts zealots yelling: oh but plain this-and-that would create faster code. No! Saving milliseconds in administration is foolishness. Do that at the public end, please.

Database administration classes

Fortunately the situation is not hopeless at all. We have written a set of utility classes for viewing and updating data from a MySQL database. The set has been used in hundreds of web applications and we know it works. The set consists of the following classes we call The Trinity:

DataBrowser class

This class eases the writing of tabular data views. Here some highlights of the class

Has been used in hundreds (really) of web applications
Uses a generic Smarty template for all instances, no tailoring needed
Gets an SQL SELECT statement and fetches the data
Easy-to add column definitions for most data formats
Option to use column specific callback functions for formatting data
Option for CSS callbacks per column
Automatic link generation for editing, deleting and inserting new data
Automatic filtering/sorting/whatever using dropdowns
Option to add new function buttons
Option to use paging
A generic template tailored for this very class

UpdateForm class

This class provides a simple way of generating forms for the most common tasks

Field types for the most common tasks
Super-simple way of adding dropdowns
Special fields like date and time
Easy-to-add hidden fields
Easy-to-add JavaScript
A generic template tailored for this class

DBUpdate class

Simple and efficient creation of database update statements
Understands checkboxes, text data and Smarty select date arrays
Easy-to-add basic error handling
No templates needed

The class files are DataBrowser.class.php, UpdateForm.class.php and DBUpdate.class.php and they should be to an appropriate directory to be included in the administration scripts. The current version has a permissive license (see the licensing page). We do not present the code here and the package is only included in a scrambled format. The PHPDocumentor generated documentation will be provided at a later stage.

The Database Handling Templates

The templates needed by the two first classes are pretty complex and therefore we do not cover their technology here in depth. They have been in production for years, experiencing some minor repairs. Some may need a rewrite and some a bit rethinking but their target being mostly in site administration the task has been postponed. Moreover - they do really work.

DataBrowser template

This template is filled by the DataBrowser class and its aim is to create a block of tabular data with update/delete buttons on each row, an optional insert button, simple paging, a title, a short description, DHTML or Ajax for selected fields, a simple edit-in-place and things like that.

UpdateForm template

This template will display a form consisting of field types like INPUT, TEXTAREA, CHECKBOX, Smarty Date and Time or a pop-up calendar. It also has some rudimentary facilities for validation. The template is fairly complex but it works. Some tidying is currently in the works..

Wizardry

For years we have been using a crude wizard that takes a database CREATE TABLE statement as an input, parses it, lets the user decide which fields he wants to display in the browse and how and the fields he wants to show in the update form. After getting the information the wizard creates the modules for browsing, editing and updating data.This speeds up development enormously. A one-table browse-edit-update sequence can normally be created within a few minutes. One of our developers created a small Call Center application from scratch in less then 20 minutes using the wizard.

The wizard is under development and will be published "when the time comes".

Creating the directory structure

We admit that having the administration site in the subdirectory of the main site is not a very good idea. However, to make things simple we have decided to put it there. Once again it is up to the developer to figure out a better solution and we believe that the developer who has been reading the tutorial to this point cannot be not totally brainless... or are you? Seriously?

The directory structure of the admin site is an almost exact copy of the main level. We have added two important directories: /icon and /js. We will install a few image files to the icon directory and a huge amount of JavaScript in the other.

Session data in a database table (optional)

What we will do for the future is add session handling for logins. For a number of reasons, however, we will NOT use the standard PHP sessions that save the session data to the temporary directory. We will save session data to a MySQL memory table using a PHP session handling class. If you do not wish to use it, then do not.

One advantage of this solution is that you can use simple SQL to find out how many logged-in users there are, their login names and a bit of other information as well. Additionally it is really nice to kick out users out by deleting their session information in the 'view users" screen. Tee hee.

CREATE

TABLE sessions (

	  ses_id varchar(32),

	  ses_time int(11),

	  ses_start int(11),

	  ses_value varchar(255) DEFAULT '',

	  PRIMARY KEY (ses_id)

	) ENGINE=MEMORY DEFAULT CHARSET=utf8;

The session.class.php is not shown here as it is too long and uninteresting. We will save it to /admin/include and also save the following file as "session.php" to the same place. But, as said, you do not need to add this now.

There are other alternatives for this approach. If you have the memcached daemon running on your server you can use it as a very fast session data repository. You can find an example here. The APC cache also has a session caching utility. Go figure what suits your needs.