DB_Table: Summary and Pre-Call

Hi, everyone, DB_Table has been in proposal since Jan 4 (that's four months almost to the day) and has generated some interesting comments, some positive and some negative. At this point, I have added to it everything I originally wanted, and some things I discovered were useful along the way. If you are not familiar with the proposal, please take a look at the PEPr site.

    http://pear.php.net/pepr/pepr-proposal-show.php?id=14

The highlights are: * Extend the DB_Table class (no external config files needed), * Build a table schema within the class to define columns, indexes, and form elements, * The first time you instantiate the class it automatically creates the table for you, * Build SQL queries that you can then filter and call with ::select() and ::selectResult * Call ::insert() or ::update() and it automatically validates the data per the table schema, * Call ::getForm() to build an HTML_QuickForm based on the table schema. ---- Earlier discussion pointed out that DB_Table might best be part of the DB package. However, Daniel Convissor has more and better things to do with his time than add somebody else's files to the DB package; the DB code as it stands now is more than enough to take all his attention (and he's done good work, too). Daniel has encouraged me that DB_Table should be its own thing, not a part of DB (if for no other reason than lack of time to evaluate it). As such, I'm ready to set PEPr into "call for votes" mode on DB_Table, as a package of its own (not part of DB). I know at least one pear-dev lister (hi Lukas!) doesn't like that idea, for a number of valid reasons; among others, he thinks that DB is the past and MDB2 is the future, and that there are enough packages with DB_Table-like behavior in PEAR now (e.g. DB_DataObject). Lukas also points out that the future PHP-native dbx library and the future DB_Schema package should solve the concerns addressed by DB_Table, but he agrees that these future solutions do not help us right now. Alan Knowles also had valid objections, primarily that his DB_DataObject package works in a manner similar to the proposed DB_Table; however, I think his opinion may have become more moderated of late. Perhaps I am wrong there; Alan, are you still against DB_Table being in PEAR? (My argument on this point is based on the fact that DB_DataObject and DB_Table make different tradeoffs between structure, reusability, and distribute-ability of the resulting classes; this difference in balance is not bad either way, they just serve different audiences and purposes.) Way back in October, Alexey Borzov didn't like the "poor man's data type abstraction" that DB_Table uses, and I don't expect he has changed his mind. Other than that, I have received a small amount of good feedback, but not on the list; it has been addressed to me privately or in the comments on the DB_Table documentation site. So that's it; unless I hear (and agree with ;-) valid and serious negative comment on DB_Table, I'll call for votes and the whole thing can be finished. Thanks to everyone for their positive and negative feedback. -- Paul M. Jones Savant: the simple alternative to Smarty. http://phpsavant.com/