This class generates code required as an interface to an existing database by reverse engineering the database. It generates a DB_Table subclass definition for each table, and a script that instantiates one instance of each DB_Table subclass, and a parent DB_Table_Database object. See the documentation block for the new class for usage instructions, and the tests/generator/tests.php script for an example.

So what’s new in release 1.5.0? The changelog says:

• New DB_Table_Database class added to package. The new class provides a model of foreign key relationships between tables in a database, and features that depend on knowledge of these relationships. User documentation for this class is provided in docs/database/manual.html.
• Added auto-increment feature to DB_Table insert() method. The value of a new $auto_inc_col property is the name of an auto-increment column (if any) or null.
• Added toXML() method to DB_Table, which emits the table schema in the MDB2 XML DTD, with an extension to describe foreign key references. This method is called by the toXML() method of DB_Table_Database, which emits an XML schema string for an entire database.

All existing users of DB_Table (and also interested people, of course) are encouraged to install the new release by pear install DB_Table-beta and to report via the bug tracker any occuring problem. But as we have a lot of unit tests for the new features, we hope that only very minor problems will occur.

Finally, a short comment on the near future of DB_Table: We are planning to work on two things in the next weeks and months. The first and most important thing is to convert the documentation from Paul M. Jones’ wiki into the PEAR manual and to update all pages to reflect the functionality of the current release. This will need a lot of work and help is always welcome. (Contact me for more details if you’re interested.) The second task is two write a script that generates a DB_Table class file from an existing table. This will make things a lot easier for both new and existing users of DB_Table. David already started to work on such a generator.

Static form elements like ‘header’, ‘static’, ‘submit’ or ‘reset’ can now easily be added to forms generated by DB_Table: you just need define an array called $frm in your extended class (let’s assume that you have instantiated this class in $obj), create a form object (e.g. via $form =& $obj->getForm(), ...) and then call $obj->addStaticFormElements($form);.

The $frm array has a very similar format like the column definition format. The key is the field name and the value is an array with details about the element. There is a special key called ‘before’ in the details array. If it is not given, or is empty (or null) the element will be appended at the end. If it is given, the element is added before the element specified via ‘before’. An example how the $frm array could look like:

var $frm = array(
    'headline' => array(
        'before'        => 'name',
        'qf_type'       => 'header',
        'qf_setvalue'   => 'Headline'),
    'submit'   => array(
        'before'        => null,
        'qf_type'       => 'submit',
        'qf_setvalue'   => 'Save data')
);

This example assumes that there is an element called ‘name’ in the form. The header element will be placed before this ‘name’ element, and the submit button will be placed at the end of the form.

For columns with 'qf_type' == 'file' there were some optimizations: If the column is marked as required, the ‘uploadedfile’ QF rule is now set instead of the ‘required’ QF rule. In addition, the ‘numeric’ and ‘maxlength’ QF rules are not set anymore (of course, the corresponding checks will still be done before inserting/updating data into the database).

Finally, I have added support for ‘hierselect’ and ‘jscalendar’ QuickForm elements.