PEPr: Latest proposals containing table config

PEPr Proposal [171]: Networking::Monitor

2004-11-02T16:24:32-05:00

Proposed package: Networking::Monitor

Proposer: Robert Peake

Purpose

To provide a unified interface for checking the availability of services on external servers and sending meaningful alerts through a variety of media if a service becomes unavailable.

Elements

The service monitoring aspect of this package is essentially a unified interface to a number of packages designed to interact with Internet services. Initially, this list includes:

Net_SMTP
HTTP_Request
Net_DNS
Net_FTP

And could also include the Net_Telnet package that is currently being proposed once it has become more stable.

The alert sending aspect is currently a unified interface to Net_SMTP, with plans to extend this to Net_SMS as well, whereby messages can be generated and sent directly from the package. This makes this package more robust in the event that the monitored servce that goes down is the SMTP relay for the package itself -- the package can still generate and send an SMTP message to an external address.

Structure

The package object inputs and stores two arrays -- one representing the person(s) to be notified in the event of a failure and the other representing the servers to be monitored.

Each person can be assigned a notification type (currently SMTP only). Each server can be assigned any number and combination of services to be monitored (currently SMTP, HTTP, HTTPS, DNS, and FTP).

Application

The most common application for this package is a simple monitoring script that can be run at a scheduled interval (via php-cli) to check remote services and send an alert if a service is down.




<?php


require('Net/Monitor.php');


$monitor = new Net_Monitor();


$alerts = array('User1' => array('SMTP'=>'user1@example.com'),


               'User2' => array('SMTP'=>'user2@example.com'));


$services = array('foo.example.com'=>array('SMTP','DNS'),


                 'bar.example.com'=>array('HTTP','FTP','DNS'));


$monitor->setAlerts($alerts);


$monitor->setServices($services);


$monitor->checkAll();


?>

Useful Features

Custom Subject and Alert Message

Net_Monitor optionally takes in parameters to customize the subject line when sending email alerts as well as a simple format for customizing alerts. The default string, "%h: %s: %m" returns, for example, "foo.example.com: SMTP: Operation timed out." Other formats are possible using this pattern.

Smart Alerts

Net_Monitor stores the previous results of its tests (state) in a user-defined file. Alerts are only sent if the state has changed. This means that if Net_Monitor is invoked on the same set of hosts/services on a regular basis, notifications will be sent only when the state of a host/service changes.

Optionally, Net_Monitor can be configured with notify_ok set to 0. This will disable Net_Monitor sending out alerts when a state changes from an error code to a code signifying everything is OK.

Net_Monitor can also be optionally configured with notify_change set to 0. This will disable Net_Monitor sending out alerts when a state signifying a potential problem changes to another state signifiying a potential problem (e.g. from 404, meaning Page Not Found, to 0, meaning down). Both settings work independently of each other.

Calling Net_Monitor::resetState() deletes the state file and clears variables associated with results for a particular instance of the class, allowing the end user to start a new monitoring session without having to restart PHP. Furthermore, calling Net_Monitor::resetHostState() with a host name and (optional) service name will reset the state for that given host (and service), allowing the end user to reset the state of a single host/service programatically through the Net_Monitor API.

Possible Extensions

Connection Time Monitoring

One proposed extension is the ability to monitor the time it takes to connect to a service and return a value. This could be accomplished using the Benchmark package. By logging this data to a database, graphs of server response over time could be generated. This idea is currently under review, mostly to ascertain how accurate the connection time values would be given that the connections depend upon external classes with variable overhead.

Document Change Monitoring

Another proposed extension is the ability to check an HTTP or FTP file against a previously stored md5 sum of the file to see if it has changed. This feature would be the responsibility of the HTTP/FTP service clients (wrappers to HTTP_Request and Net_FTP) to accept an array of arguments containing the server fqdn and the file to check instead of just a string of the server fqdn.

It is unclear if similar behavior extended to SMTP or DNS would prove useful. Ideas include issuing a VRFY command over SMTP to verify that an account exists on the server or checking that either a zone file has changed or a particular fqdn's IP address has changed on the DNS server.

PEPr Proposal [60]: RFC::How the QA Team will work.

2004-04-26T13:28:16-05:00

Proposed package: RFC::How the QA Team will work.

Proposer: Helgi �ormar �orbj�rnsson [Wishlist]

Title: RFC - How the QA Team will work.

------------------------------------------------------

Author: helgi at trance dot is, smith at backendmedia dot com

Revision: 2

Status: Active

There has been talked about forming QA team, but no action yet taken. The following is proposal of how the QA team will work, what rights they have and so on.

The Issues

-----------

There is no official QA team for PEAR. There are only a few people who try to help with QA issues but they don't have any official status or rights to resolve issues themselves if needed. PEAR claims quality but that can't be met if there is no real QA team. PEAR group has been talking about fine tuning karma for all users so the current "user has access to everything under /pear in cvs" karma policy will be eliminated and thus QA needs special karma when that happens.

More importantly, there is currently no formal process or entity to handle orphaned packages or urgent fixes to packages.

To summarize the problem

No QA team = can't claim Quality
Nobody has defined how the QA team is supposed to work, how it should be structured and what its rights (karma) are supposed to be.

The Proposed Solution.

-----------------------

small side note:

Karma in this context doesn't just mean "technical" karma but also "political", meaning that they not only have the necessary access rights from a technical perspective (which currently most of the pear devs have anyways). They also have the right to commit to any part of the cvs if they deem it necessary (obviously following the necessary regulations)

QA team membership:

How the initial members are chosen:

If there are more applicants than seats, there should be an open election, where everyone may cast as many votes as there are seats (only 1 vote may be cast per candidate). Of course, if there are less people than seats, all may be accepted and the remaining seats can be filled by QA group vote. Once the core team is formed all further team members can be voted in as per the rules stated below.

There will be a QA core team with a limited number (no more than 7, with the pear group this should give a sufficient amount of people with enough karma that can react to bad releases) people with extended "core-QA-karma". In order for the QA core team to react quickly, the core QA team should be spread out across all time zones as good as possible. This rather small number should empower the QA team sufficiently to handle issues but doesn't trivialize access rights.

Note:

This issue needs more discussion since Klaus raised a good point in his post

http://news.php.net/article.php?group=php.pear.dev&article=26756 but the problem is that it isn't wise to give many users so much karma.

All other people interested are free to join the QA team. However potential new members for the QA team (core and non core) must be voted in by a 2/3 majority of the existing members of the QA team (core and non core). This is to prevent that the addition of new members is done even though there is a considerable amount of opposition, as this could lead to internal quarrels which could result in reducing the QA teams ability to efficiently address QA issues. Removing a member from either group requires a 2/3 majority as well.

For casual helpers the QA mailing list will of course remain open.

All members of the QA team (core and non core) are eligible to participate in QA team votes.

Any member that leaves the QA team loses all his special karma which he may have received due to his membership. If any member of the core QA team leaves and as a result a time zone gets under staffed, QA should actively try to find a replacement.

Notes:

When voting for a new member voters must be sure that the person has been helping with bug fixes in the past or has the potentials to help with that.

Voting:

All votes (except membership related votes; see above) require a simple 50% majority. Any member of the QA team may call for a vote at any time. All voting is done on the QA mailinglist.

The core team may overrule any decision (this includes votes on memberships) of the QA team and may decide to hold their own internal vote to make the ultimate decision on how to proceed. Furthermore, the core QA team may also hold votes without even consulting the QA team. However this should be only done in rare cases. All members of the core QA team may make decision on their own if a decision is time critical (like pulling a broken release). However the core QA team should be aware that making too many decisions on their own may lead to alienating the other members and therefore if possible it should always be attempted to at least consult other members of the team.

QA rights/responsibilities:

Fixing bugs/making releases

If any QA related issues are found in a package that QA has not been granted permission to change without consulting the maintainer,the QA team will file a bug report. If the issue remains unresolved for 1 month (2+1+1 weeks; see below), QA may fix it themselves.

If the issue isn't fixed with in two weeks QA will email the maintainers about the issue (if the bug system won't have auto bug report notices every X week in the future) and if the problem isn't fixed within one week from that, QA will send yet another email to the maintainers and if no answer nor fix to the problem is provided within one week, all members of the core QA team will get the permission to modify any file needed to fix that QA issue as well as make a new release.

If any major QA issues are found in any package and the QA team doesn't have permission to change that package without contacting the lead first then the QA team will file a bug report. Any major issues can stay open for 2 weeks (5+5+4 days; see below), QA may fix it themselves.

If the issue isn't fixed within 5 days QA will email the maintainers about the issue (if the bug system won't have auto bug report notices every X week in the future) and if the problem isn't fixed with in 5 days, from that QA will send yet another email to the maintainers and if no answer nor fix to the problem is provided with in 4 days, all members of the core QA team will have permission to modify any file needed to fix that QA issue as well as make a new release.

The same time frames apply when the QA team want to make a release because of unreleased fixes/improvements which are only available via CVS, or when the QA team wants to determine if a package has been orphaned (using the time frames specified for non major issues).

The QA team can decide what are major issues after discussion on the QA Mailing-list.

The QA team will for this reason keep track of those QA issues in their pear web subsection. This would only be for having overview over which package maintainers need to be emailed for reminders and such things.

Orphaned Packages

The QA team can use the above stated rules to determine if a package is orphaned. The core QA team gets lead rights on all orphaned packages until the original maintainer returns or a new maintainer is found.

Deleting Package releases

The core QA team also has the permission to delete any release that might have any issues that have been found after the release, to reduce the effects of the problem. This right must be exercised with caution.

Package maintainers can also grant QA the rights to make a releases for their packages.

pearweb QA subsection

It seems that there is a lack of QA material in the manual that people agree on and there is also need to make it move visible for people so they will actually follow those rules/guidelines. The QA team will therefore get its own QA subsection in the manual and will have control over it just like package maintainer controls package related docs in the manual. The QA team also gets its own subsection on pearweb so people can more easily access QA material which is too dynamic or just related to the QA team own internal documentation purposes. There the QA will, for example, publish their latest decisions. Furthermore here the QA team will be able to provide interfaces to QA team services. For example, here the QA team could offer an interface for maintainers to configure the access rights they want to grant the QA. Finally the core QA team can add QA related notes to each package homepage to communicate QA related information to the user base.

Approving first stable release

The QA team needs to approve the first stable release of any major version. For this purpose maintainers upload the release to PEAR web

and contact the QA team with a link to the release, then QA will decide if the release is ready or not. The core QA team will at this point approve the release through PEAR web and release it for the maintainer.

Notes:

The QA team must always inform the current lead maintainers of any changes that are done to a given package using the currently configured email addresses on pear web.

The core QA team may delegate tasks as much as possible to other QA team members. However no access rights will be assigned just for the sake of delegating a task (so members of the QA team may package a new release, but only members of the core QA team will have the necessary rights to upload the release).

Summary of the solution

QA core group access rights:

Max 7 core members that get the core-QA-karma.
the core QA team will get more permission to fix issues and make release of packages if reported problems are not fixed in a specific time frame
the core QA team assumes lead over orphaned packages
the core QA team gets the rights to delete releases of packages if it determines that the release has severe issues
the QA team is allowed to add QA related notes to package homepages
QA team needs to approve an first stable release for a given major version number (done by votes)
the entire QA team will identify QA problems, will help writing QA related documents, will help people resolve their QA problems and such things
More focus is needed on writing QA related things in the manual and make then more visible
Make a little QA corner at pear.php.net so QA is more visible for people and package devs are more aware of the QA team and how it works.
keep track of what QA does regarding packages that QA doesn't have permission to edit through a wiki of some sort

Actions Required if accepted.

-----------------------------

Forming of the QA team, electing the persons who should for the core of the QA team.
Giving the core dudes full CVS karma on the pear CVS module, as well as full access rights to package management part of pear web
Make that little QA pear page
Improve the QA manual pages
Discovering which packages' lead(s) allow QA to help keeping their package QA approved
Better coordination of the work which is done, who is going to do what. Know in advance who is going to write some more entries to the manual and so on.
Make a wiki page of some sort for the info tracking regarding QA editing package that QA doesn't have permission to edit.

Change log

----------

Initial Release : 24 March 2004

Revision 1 : 26 March 2004

Fixed some typos (left summarize since Alan did it that way so I can't see anything *wrong* with it)
added Lukas as author
added in "Issue" about pear group
added that more discussion is needed about core size
added about if member leaves the team
added small side note what the term Karma means in this RFC.
added regarding new member in the QA team.
No voting for pulling releases
How the initial members are chosen.
Changed name of section QA core group access right to QA rights/responsibilities
Made better sub sections for readability in QA rights/responsibilities
added how Orphaned Packages will be handled
More specific about Deleting Package releases
Reworked the wording of things in many places

Revision 2: 26 April

Forgot to add the date of revision 1 ;/
Spelling and grammar corrections provided by Klaus :)
Boosted core size to 7.
Changed the time frame regarding packages that haven't allowed QA to modify.
Changed how things are handled around first stable release

Comments

----------

Klaus Guenther: Wants to boost up the core size to 10-15 members so the team can always react to any situation more quickly see http://news.php.net/article.php?group=php.pear.dev&article=26756 for more details.

Also mentions that there is needed some clarification on what happens when a core member leaves the team, and that voting needs some time frame.

Feels that QA could make use of PEPr for sending out emails to maintainers about bug reports and such.

For Rev. 1 Klaus came with some ideas how orphan packages should

be handled on the pear web.

"That will require a new global maintainer: "PEAR QA", which would be merely a pseudo user. ......."

(We leave the implementation details for a more advanced rights management solution to the pearweb team)

Alexey Borzov: Is against the core of QA, everything should be done in volunteer (isn't pear all about that?) also dislikes the voting idea, thinks person should only be accepted if he provides many quality bug fixes. packages should not be deleted if the case isn't extreme, if minor issue then down grade it's state.

His entire comments can be read here http://news.php.net/article.php?group=php.pear.dev&article=26757

Daniel Convissor: Feels that time frame allowed for packages that haven't given QA the rights to modify them, be to long (Was fixed in Revision 2 )

PEPr Proposal [14]: Database::DB_Table

2004-01-01T20:32:35-05:00

Proposed package: Database::DB_Table

Proposer: Paul Jones

Proposal: DB_Table

Recent Changes

DB_Table now supports HTML_QuickForm rules for elements derived from table columns, and supports setting of default values for QuickForm elements. Documentation for these is also complete.

Except for (1) automated discovery of existing table definitions, and (2) automated alteration of tables to match the class table definitions, DB_Table is now feature-complete. I expect to move it to beta, unless serious bug reports come in.

Overview

DB_Table is a wrapper for DB that acts as an interface to an SQL table, providing automated table creation, predefined and automated select views, automated insert and validation of inserted data, automated update and validation of updated data, automated form creation based ont eh table columns definitions through HTML_QuickForm, and a form of data type abstraction that forces the database to store date and time data as strings in ISO format.

The main benefit of DB_Table is that a developer can, with one file, distribute a table interface class that creates the table automatically and validates all data going into the table, regardless of the database backend, and creates input forms based on the table columns.

See the complete user-documentation, which includes extensive examples and explanations (much more than is covered in this proposal) here.

See the source code for DB_Table here.

Apology In Advance

Not to beat a dead horse, but this proposal is a new cover for a revised version of DB_Simple. Recall that there was no vote on DB_Simple, so although the three commentors were in the negative, it was not rejected.

The recent talk of the DB_OO class and the Propel/Creole project leads me to believe that others like myself are unsatisfied with DB_DataObject, MDB, et. al. While they are fine classes, they are not well-suited to my needs, and the fact that others are proposing code similar to DB_Table makes me think that it could be a useful addition to PEAR.

I have gone over the old DB_Simple thread and I think I have addressed some of the concerns there. Lukas, Alexey, and Alan were the main detractors of DB_Simple; perhaps the intervening time and the similar proposals will cause them to think differently about allowing DB_Table into PEAR.

I would prefer for DB_Table to be in the DB package, rather than a package of its own. In line with that preference, I have contacted Daniel Convissor (lead for DB) numerous times over the past few weeks, but he has been unable or unwilling to assess DB_Table as yet. As such, I cannot say one way or another if he will accept it into DB, so I will continue to maintain this proposal.

Introduction

DB_Table is a wrapper for DB (which abstracts API calls to databases) that provides MDB-like capabilities, especially as regards data type abstraction. It is not a data object class, it is a table interface.

Among other things, DB_Table provides:

Complete end-user documentation as well as inline comments.
A constructor that takes an existing DB object, so you can re-use the same connection object for multiple tables
API abstraction through DB
data type abstraction by avoiding and extending native SQL data types for date and time
an in-class column definition system (no external config file required, which significantly eases extension and distribution of classes based on DB_Table)
an in-class index definition system (no external config file required)
an in-class HTML_QuickForm definition system for form elements based on column definitions (no external config file required)
automated table creation (based on the defined columns and indexes) at object instantiation time; this means no need for a separate table-creation script
an in-class "view" (i.e., predefined SELECT) system (no external config file)
automated insert and update based on associative arrays (as per DB::autoExecute)
automated validation of insert/update data on a by-column basis at insert/update time
automated creation of HTML_QuickForm objects based on the table column definitions
easy-to-understand configuration options using class property arrays
clean-running (no notices under E_ALL) and well-commented code compatible with both PHP4 and PHP5

DB_Table is not:

a competitor for DB_DataObject; it only acts as a table manipulation (create/insert/update/delete) and reading (select/view) device, not as a data encapsulator
a code generator; you extend DB_Table yourself and define columns, indexes, and views inside the extended object
supported for all PHP databases; only fbsql, mssql, mysql, oci8, pgsql, oci8, and sqlite are available at this time
a replacement for MDB or DB_DataObject, although it walks a similar path.

Why Not Use (or Contribute To) Package X Instead?

DB: DB_Table extends (technically, it wraps) DB. I'd be happy to have DB_Table become a part of the DB package if only Daniel Convissor can take time to assess it for inclusion.

(M)DB_DataObject: Until recently only supported INT and STR types (update: Alan notes that it now supports DATE, DATETIME, TIME, MYSQLTIMESTAMP, but still no FLOATs), not as easy to get started with, it auto-generates classes (update: Alan notes that this is now optional). Goes at things exactly backwards from the way I (and apparently others) like to proceed. It uses the class to generate a .ini file, not the other way around. Similarly, the createTables script only creates from a .ini file, not from the table() and keys() setup methods. In short, its philosophy is quite different from DB_Table. This is not bad, just not my preferred way of doing things.

DB_QueryTool: no easy way to just "type in" the baseline query elements, it uses its own update() and insert() code (not extended from DB), lacking end-user documentation. Seems to be going for programmatic SQL generation.

MDB: Overly complex, very heavy, user documentation is lacking, is more of an alternative to DB (as a database interface) than a table interface proper.

MDB2: Less complex than MDB, but as with MDB, is more of an alternative to DB (as a database interface) than a table interface proper.

DB_Schema: It doesn't exist; or rather, it exists only as a thought in the minds of some developers.

Data Types

Similar to MDB, DB_Table abstracts a number of data types, defined as

constants within the class:

DB_TABLE_COL_STRING: variable-length string, typically VARCHAR, up to 255 characters
DB_TABLE_COL_SMALLINT, _INTEGER, and _BIGINT: 2-, 4-, and 8-byte integers, respectively
DB_TABLE_COL_DECIMAL: fixed-point decimal value, typically DECIMAL or NUMBER
DB_TABLE_COL_SINGLE: single-precision floating-point number, typically FLOAT
DB_TABLE_COL_DOUBLE: double-precision floating-point number, typically REAL
DB_TABLE_COL_DATE: ISO standard date, "yyyy-mm-dd" *
DB_TABLE_COL_TIME: ISO standard time, "hh:ii:ss" *
DB_TABLE_COL_DATETIME: ISO standard date and time, "yyyy-mm-dd hh:ii:ss" *
DB_TABLE_COL_UNIXTIME: 32-bit Unix Timestamp +
DB_TABLE_COL_CLOB: a character large-object, typically LONGTEXT or CLOB

* Forces the database to store as a string.

+ Forces the database to store as a 4-byte signed integer.

Note that instead of attempting to maintain and convert database-native dates and times, DB_Table uses string data types to represent those kinds of data, thus forcing every supported database to store the information in a known recognized format. This is different from MDB, which uses the database-native storage format and attempts to convert back-and-forth between the MDB data type and the database native type.

This "forcing of type storage" allows very easy portability between database servers; you do not need to convert your query terms to the database native format, you can just write them the way you know the database will store your data (because DB_Table is forcing it to be stored that way). Yes, you lose a lot of power that individual database back-ends may provide vis-a-vis their own data types; but then, if you are custom-writing your app for a specific RDBMS, you're probably not going to be able to port those database-specific abilities anyway.

The benefit of the "forced storage" in DB_Table is that when composing a WHERE clause, you do not need to know the native format of the SQL data type; you use a known standard format for dates and times. No conversion of types is necessary; the data is already in the table in a known format.

The drawback is that the database engine does not "know" that (for example) a DB_TABLE_DATE field is actually a date, because it is stored as a string. However, this should only present problems when using native SQL calculations (e.g., YEAR(date_field) or HOUR(time_field)).

This is one of the primary conceits of DB_Table: that you can force the database to store things the way you want them to be stored, thus avoiding the need to convert back-and-forth between native database types when moving from one RDBMS to another. (C.f. the comments from the SQLite guys on their implementation as well.)

Index Types

Also similar to MDB, DB_Table abstracts index creation, defined as constants within the class:

DB_TABLE_IDX_NORMAL
DB_TABLE_IDX_UNIQUE

Column Definition

To support automated table creation, automated SQL generation, and automated validation of insert/update, DB_Table requires that you define your table columns in advance, using the DB_Table $col property. Here is an example column definition:




$this->col['id'] = array(


    DB_TABLE_COL_TYPE    => DB_TABLE_COL_INTEGER,


    DB_TABLE_COL_REQUIRE => true


);

That will define a table field for the DB_Table class called 'id'; DB_Table recognizes that the column contains unsigned integers, and that values for this column are not allowed to be null.

Here is another example:




$this->col['cost'] = array(


    DB_TABLE_COL_TYPE    => DB_TABLE_COL_DECIMAL,


    DB_TABLE_COL_SIZE    => 10,


    DB_TABLE_COL_SCOPE   => 2,


    DB_TABLE_COL_DEFAULT => "'0.00'"


);

That will define a table field for the DB_Table object called 'cost'; DB_Table recognizes that the column is a fixed-point decimal 10 digits long with 2 places for the decimal portion, defaults to a value of '0.00', is allowed to be null, and has no index.

Automated CREATE

When you call the DB_Table constructor, you can ask it to set up the table (based on the column and index maps). Just pass the proper flag to the constructor:

DB_TABLE_CREATE_SAFE: Creates a table only if it does not exist in the database
DB_TABLE_CREATE_DROP: Drops an existing version of the table and re-creates it

Automated SELECT

To support automated SELECT statements via select() and selectResult(), DB_Table lets you define baseline SQL clause sets in the $sql property array. Here are some example view definitions:




$this->sql['list'] = array(


    DB_TABLE_SQL_SELECT => 'id, username, email',


    DB_TABLE_SQL_FROM   => $this->table,


    DB_TABLE_SQL_WHERE  => "division = 'Information Technology'",


    DB_TABLE_SQL_ORDER  => "username",


    DB_TABLE_GET    => DB_TABLE_GET_ALL


);





$this->sql['item'] = array(


    DB_TABLE_SQL_SELECT => '*',


    DB_TABLE_SQL_FROM   => $this->table,


    DB_TABLE_SQL_WHERE  => "division = 'Information Technology'",


    DB_TABLE_GET    => DB_TABLE_GET_ROW


);

When the select('list') or select('item') method is called, DB_Table will build an SQL select statement from these clauses and return the row results as an array.

When selectResult() is called instead of select(), DB_Table will return the results as DB_Result object.

DB_Table supports GROUP BY, HAVING, and JOIN clauses as well.

The select() and selectResult() methods allow for ad-hoc filters, ordering, and limits.

Automated INSERT and UPDATE With Validation

DB_Table uses DB::autoExecute() in its insert() and update() methods, which means all you need to do to insert or update table rows is pass an associative array where the key is a field name and the value is the field value.

In addition, because the DB_Table instance has a defined column map, it knows what to expect from every field. Thus, it can pre-validate all INSERT and UPDATE values to make sure they match the column requirements (data type, size, decimal places, not-null, and so on) before attempting to connect to the database. This also allows developers to add customized validations for insert and update calls.

DB_Table does not need to convert back and forth from database-native data types, because all data is stored in a format consistent with the DB_Table data type (e.g., DB_TABLE_DATETIME is always in "yyyy-mm-dd hh:ii:ss" format in the table, and attempting to insert or update with a value not conforming to that format will fail validation). Likewise, if a column is defined as DB_TABLE_NOTNULL, you cannot insert a null value (or update to a null value).

Automated Form Generation

DB_Table can generate HTML_QuickForm elements based on the column defintions with DB_Table::getForm(). This makes getting initial application developent very fast, as you don't need to code your form pages by hand.

The default form elements are very generic, so DB_Table allows you to specify HTML_QuickForm options inside the column defintions, thus ensuring that form fields are presented to the user in a consistent manner. For example, to define a column and add HTML_QuickForm element options:




$this->col['gender'] = array(





    // column definition for the table


    DB_TABLE_COL_TYPE    => DB_TABLE_COL_STRING,


    DB_TABLE_COL_SIZE    => 1,


    


    // form definition for HTML_QuickForm element


    DB_TABLE_QF_LABEL    => 'Your gender:',


    DB_TABLE_QF_TYPE     => 'select',


    DB_TABLE_QF_VALS     => array(


        'm' => "Male",


        'f' => "Female",


        'h' => "Hermaphrodite",


        'e' => "Eunuch"


    ),


    DB_TABLE_QF_ATTRS    => array('size' => '4')


);

DB_Table also supports setting default values for form elements, and supports HTML_QuickForm rules.

Known Issues

DB_Table has only been tested with MySQL.

DB_Table needs unit tests.