Re: Feature additions to DB_DataObject_FormBuilder

A solution would be to create a "wrapper" class for this, which takes an argument ($tablename) and returns a reference to the corresponding DataObject, generated on the fly. For compatibility reasons (if needed), the DataObject/DataObject_xxx.php files could be overwritten with a class that contains a reference to this wrapper. In the wrapper class, all the stuff could be taken from an .ini file on the fly. However, I don't know how to deal with keeping this wrapper in sync with createTables.php improvements... Well, this sounds too complicated. The difference between my idea and your RDBEdit is that my tool doesn't deal with data in the tables, only databases, table structure, validation rules etc. It would be very nice to have a discussion on the naming conventions of configuration options of the DB_DataObject and DB_DataObject_FormBuilder packages. FormBuilder options placed in DataObject classes (fieldLabels, for example) should have a prefix to avoid confusion (imagine a table with a field called "fieldLabels"). Some config options have underscores in their names (e.g. hide_primary_key) while others have another naming convention (createSubmit). At the same time, a discussion would be great about placement of configuration options. Justin Patrin wrote:

That's nearly what I was trying to do. My plan was to have the DB already there and have the createTables.php script create default objects, then have a web-base GUI which allows you to choose display fields, validation, links, etc, configure it all for you in the ini file (it *could* be in the DataObject classes, but those are harder to automate changing after createTables.php creates them), then let you edit any table and any data, al-la RDBEdit. Ideally, I would want the DataObjects created dynamically on the fly, but that's not how DataObject works, so I would autogenerate and cache them. Yes, I have all of the configuration in one file in my project, which makes things nice and central, but can also get very complicated. I was about to write a configuration admin when I found this stuff. Mocsnik Norbert wrote:

Justin Patrin wrote:

My changes only (for now) deal with the select boxes.

Cool! I was afraid we made the same improvements.

I like your changes, though, I would have wanted them eventually too. Could your options also be initially set from the ini file?

My point of view actually is to set everything runtime as required. This is because in different situations you may have different needs for displaying the same form - this may depend on different user rights, for example. However, as you can see, all my improvements $do->fieldsToRender $do->userEditableFields $do->forced_values $do->select_add_empty are based on your DataObjects-based classes, so you could put your default settings into these files (DataObjects/DataObject_xxx.php) also. This is the same as $do->fieldLabels, $do->textFields or $do->dateFields in the original version of FormBuilder.

I'm working on a solution to make table editing as simple as choosing which table you want. No manual code generation and such. All through config files. To get an idea of what I mean, check out http://rdbedit.sf.net. I made that before I realized that there were other PEAR modules I could use to make my life easier.

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. 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. Regards, Norbert Mocsnik