Re: Feature additions to DB_DataObject_FormBuilder

I've altered my copy to work with a new config file for FormBuilder names database.formBuilder.ini, which should reside in the schema directory (this can be changed, of course, but it must have the database name in it as these are DB specific options). The new ini file holds the [tableName__display_fields] and [tableName__order_fields] as before. I added a _loadConfig function which loads the database's ini file. I've added a call to this in the constructor. Other than that, the only change is in getSelectOptions(). The new source file is attached. Justin Patrin wrote:

Good point. The code to handle multiple entries for those is already in the copy I sent you, it just has to be changed to work off of the internal vars. I suppose I can just write a wrapper which reads from another ini file...or we could add an ini file for the FormBuilder. If people are worried about ini file size and parsing time, they could use caching, say using PEAR::Cache or simply var_export the parsed ini file and cache that manually. It would cut down on ini the parsing time at least. Markus Wolff wrote:

Mocsnik Norbert wrote:

I've checked it. You have everything in 1 .ini file, or am I wrong? I like this. I wonder what the others think about it.

Unfortunately, I got the private mails from the both of you before I read the posts on the lists, so my answers didn't make it here. But here's to this question what I've already answered to Justin: <SNIP> thanks for sending the code, I'll be able to have a look at it tomorrow. I can say one thing right now, though: I think it's not such a good idea to add these options to the databasename.ini file. Two reasons: 1. If you make changes to your database and run the createTables script again, all the settings you've made will be overwritten. You'd need to backup everything first and then reapply what you had changed. 2. That file is loaded and stored in a global variable upon every request that uses a DataObject. If you're dealing with a huge database, that's already a damn big array, and chances are good that you'll only need a very small portion of that data to work with. Storing form field information there as well will only lead to further bloating of that array, eating up memory even when not needed. This is pretty much why I prefer to do settings like these in the code of the dataobject itself - and in fact the possibility to set these options in code are already there. To meet your feature list, the FormBuilder just has to accept more than one field for the display_field and order_field settings. </SNIP>

By the way, my dream is a tool for developers which a) allows you to define a database, set some validation rules, edit field labels and so on b) after making the definitions: create the database, generate and run an .sql script for creating the tables, call createTables.php to create table classes, set the parameters of the generated DataObjects-based classes (fieldLabels, textFields etc.), and somehow tell both FormBuilder & DataObject to use the given validation rules for each table (on both client and server side) that you've specified. If someone has time and experience for being part of such an open source project (based strictly on PEAR), please let me know. Opinions are also welcome.

AFAIR, both Lukas and Alan have expressed their interest in making an MDB version of DataObject one fine day. Using MDB's XML schemas and spicing up the GTK designer with the possibility to add form field and validation information for each database field might do the trick already. CU Markus