Re: DB_DataObject_FormBuilder frozen link fields

On 12/15/06, arnaud sellenet <demental@free.fr> wrote:

Thanks for your answer. Indeed I've read the doctrine discussion and the right think to do now is to make a driver-based form builder to handle several datasource (and form generation classes). for now I'll do something like this in the object from which all my DO inherit : function prepareLinkedDataObject(&$do,$field) {

        if (is_array$this->fb_userEditableFields) && !in_array($field,$this-

fb_userEditableFields) {

                $pk = DB_DataOBject_FormBuilder::_getPriparyKey($do);
                $do->{$pk} = $this->{$field};
        }

} So do you mean DB_DataObject_FomrBuilder is about to be deprecated ?

Not about to be...but I do have a FormBuilder2 which is started. See my earlier e-mails about it.

Le 16 déc. 06 à 07:46, Justin Patrin a écrit : On 12/15/06, arnaud sellenet <demental@free.fr> wrote:

Hi. I noticed that when a field is not declared as a userEditableField and it's a link, frombuilder builds a select (or radios), fetches the linked records and freezes it. Do you see any good reason not to create a static field instead and fetch only the linked record (if it exists) in this case, which can be (dramatically sometimes) cpu/memory saving? Do you think it's worth submitting a patch ?

I understand your use-case, but as the code currently stands this is not an easy thing to do. For my own systems what I've generally done for this is to use a prepareLinkedDataObject callback to set the key to the currently selected value so that the element only gets the current option. I'll keep this in mind for the future. Feel free to open a feature request for FB in the bug system. -- Justin Patrin -- PEAR Development Mailing List (http://pear.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php -- PEAR Development Mailing List (http://pear.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php

-- Justin Patrin