Re: Feature additions to DB_DataObject_FormBuilder

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

-----Original Message----- From: Mocsnik Norbert [mailto:norbert2003@mocsnik.hu] Sent: Monday, December 01, 2003 4:15 PM To: Justin Patrin Subject: Re: [PEAR-DEV] Feature additions to DB_DataObject_FormBuilder I made something similar and I wanted to post it to the list at the end of this week. What I made is: a) added "fieldsToRender" configuration option

     // a field will only be rendered if:
     // 1. it is a primary key
     // 2. it's explicitly requested in $do->fieldsToRender array

b) added "userEditableFields" configuration option

     // $do->userEditableFields may contain some field names;
     // the other fields will be automatically freeze()-d;
     // this functionality is ignored if $do->userEditableFields is not set (backward compatibility)

c) added "forced_values" configuration option

     // useful if you want to set some fields internally before processForm() (e.g. storing user id in the "userid" field)
             $do->forced_values = array(
                 'owner_user' => $logged_in_user
             );
             [...]
             $form->process(array(&$fg,'processForm'), true);
d) table lookups: insert an additional empty option (value="") as the first element of the <select> listbox
     // $do->select_add_empty = true;

Justin, is your solution really similar to this, or are you talking about table links (which fields to show in the <select> element and so on)? I've attached the modified file. Search for the string 'QLZ' and you'll find my improvements. Let me know your thoughts. Justin Patrin wrote:

The altered file is attached. The ini file changed is the databasename.ini file. It has no alterations, only additions. There are two new sections. [tablename__display_fields] 0 = column1 1 = column2 ... There can be any number of display fields. For lack of a better way to

do it, I used numbers starting at 0. This sets the order of the displayed column data. The fields are comma separated (could be configurable). [tablename__order_fields] 0 = column1 [ASC|DESC] 1 = columns [ASC|DESC] ... Basically the same as the __display_fields entries except that you can

include any valud order statement. You could even do: 0 = column1, column2 DESC Arnaud Limbourg wrote:

Hi, sounds good ! Sent the code here i'm sure markus (the maintainer) will have a look at it ;) Arnaud.

I've made some additions to DB_DataObject_FormBuilder that involve some additions to the DB_DataObject ini files. Namely, support for multiple sort and display columns, configured per table in the ini

file.

I'm not sure that the code I wrote is entirely in the correct place,

but I don't know who to ask about it. Anyone want to point me in the

right direction?