Re: Using linkDisplayFields of FormBuilder

On 4/25/06, Thomas Supercinski <thomas@corp.htcomp.net> wrote: > Justin, Please send replies to the list. > > Justin Patrin wrote: > > 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). > >> > Agreed. Thanks for the reminder. I had at one time placed some code (var > declarations) within the generated code portion on another project, only to lose > it later and sort of forgot that regenerating didn't replace everything. > > > > 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. > Please indulge a greenhorn, what are the issues involved that make extending the > do's not such a great idea? Because DO's factory method is the supported way to get an instance of a DO and (IIRC) it doesn't support dealing with objects extended from the base DO for a table. You *could* use one config for generating and one config for production, making the config for production have an extra part to the prefix...but this is just extra work for really no extra flexibility, unless you're going to have multiple sets of extended classes for different applications or something... > > > >> 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. > I guess it could be possible to hack/replace the factory to use the 'customized' > classes, but probably not worth the effort now or confusion it'd create later. Yes, although switching the class prefix would also work. > > > > 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. > Using prepareLinkedDataObject works great. I should have seen that in the docs. FB's docs and options are copious, I don't even remember the specifics of all of them at once. ;-) > > > >> 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. > OT - It seems there's pressure to do everything with MVC which isn't necessarily > necessary, but it does seem helpful. Any other tips on getting at least closer > to resembling MVC and still using FB? Well, MVC is helpful in some circumstances, but there are other options. Using FB doesn't break the paradigm *too* much. You put "View" options (and sometimes code with the callbacks) in the DO (Model) and FB does mostly "View", but also deals with data (Model). However, the separation of M and V still works pretty well with DO being the M and QF being the V. FB is just the glue between them (a part of the Controller?). But this is just rationalization really. If you're worried about putting your View options in the Model then you can set FB's options without setting them in the DO itself. There are 6 or so ways toconfigure FB and these can be done in a couple of different ways. See: http://pear.reversefold.com/dokuwiki/doku.php?id=pear:db_dataobject_formbuilder:configuring_formbuilder > > I'm just beginning to refactor a legacy app built with no separation of > _anything_ and no data abstraction with sql strewn all over the place, a.k.a big > ball of spaghetti. I have a soft spot for pear packages because they seem to > just work and I like the idea of small building blocks rather than a (usually) > overgrown framework that, of the ones I've seen, don't seem as easy to pick up > and use as pear packages or are not geared towards enterprise apps (I could be > very wrong on this). I've looked at many frameworks but none seemed to click > with me. I assume you are fond of PEAR packages, at least to some extend, but > do you have any suggestions as to options out there? Sorry, I haven't really worked with any frameworks so I don't have any suggestions for you. > > Thanks for the quick response. I hope you are doing well. > > > Tom > > > > -- > > Justin Patrin > > > -- Justin Patrin