Re: Using linkDisplayFields of FormBuilder

On 4/25/06, Tom <thomas@htcomp.net> wrote: > Hello all, > > I've successfully generated my DataObjects for my database and have a > set of objects that extend these generated classes so that my logic is > separate from the generated code (so that any slight schema changes > won't overwrite my code). > Schema changes won't overwrite your code. Put it outside of the comments which surround the autogenerated section and it won't be touched. This is a far better idea generally than extending these objects. > My question concerns using FormBuilder to change the displayfield for a > linked dataobject. For example, I have table1 and table2. table1 is > extended by table1extended class. I create a do from this extended > class and pass that to formbuilder. table1 has a link to table2, but > I'd like to make table2 use a different field when being displayed by > the form generated for table1 *without having to place the > fb_linkDisplayField variable into the generated do for table2*. I'd > prefer to keep that out of the do. Putting it in the extendedtable2 > class is alright, but how do I make formbuilder see that class instead > of the base do that is generated? Even better, I'd like to be able to > effect the way table2 is displayed in a form(s) generated from table1 > from the page that is creating that form. (Page one with a form > displays table2's name field, while page two with a form displays one of > table2's other fields). FB uses DO's factory method to create the DOs, so AFAIK there's no way to use extended classes. You can set the values/options in the linked DOs using the prepareLinkedDataObject function, although I suggest setting it in the DO as this is the normal way of doing it and means you don't have to put the same code in every DO which links to the linked DO. You can also set your own callback for the prepareLinkedDataObject with prepareLinkedDataObjectCallback. > > This may fall more into how to structure my application. I want to > separate the generated do code from my 'business logic' and separate the > form/display details from the business logic. > FB definately breaks the MVC paradigm, but you can always set the options from within your own applications by just setting it in the DO instance in the calling script (instead of setting it in the DO class) or setting it in the FB instance. -- Justin Patrin