Re: DB_DataObject Can getLink() return child class of DB_DataObject

On Thu, 31 Mar 2005 15:25:57 -0800, Ben Ford <ben@naturestears.com> wrote: > Justin Patrin wrote: > > > On Thu, 31 Mar 2005 14:55:24 -0800, Ben Ford <ben@naturestears.com> wrote: > > > >>Is there an existing way to have getlink() return a child class of > >>DB_DataObject? > >> > >>I was going to extend the getLink() to allow this but wanted some > >>feedback first. > >> > >>Also, is there a better way to do this? > >> > >>ie. > >>require_once 'DataObjects/Odb_item_line.php'; > >>class ODBItemLine extends DataObjects_Odb_item_line { > >> > >> public function getDescription() > >> { > >> $item = $this->getLink('odbItemId'); //returns wrong type! > >> return $item->toString(); //WILL NOT WORK!! > >> } > >>} > >> > >>require_once 'DataObjects/Odb_item.php'; > >>class ODBItem extends DataObjects_Odb_item { > >> > >> /** @return string String representation of item. > >> * This can change based on various properties. > >> */ > >> public function toString() > >> { > >> //Fancy logic to calculate the name goes here... > >> return $itemName; > >> } > >>} > >> > >>One way around this: > >> Put my extended code directly into the Auto-Generated class. But this > >>ties my class names to closely to the table names. I like the extra > >>degree of space I get when extending each class myself. > >> > >>I would also have to use the factory method of instantiation which for > >>some reason I was trying to avoid... > >> > >>Thanks in advance. > >> > > > > > > I would suggest using the factory anyway. > > > > getLink uses the factory to get the DO of the linked object. It's best > > to put code specific to the table into the autogenerated class. You > > can also always change which object any of your autogenerated clases > > extends from. > Is the way I'm extending each DataObject unusual? In my mind, it has > both positive and negative effects. The negative might out way the > positive and that is exactly what I am trying to figure out. That's outweight. ;-) I'm not sure what you're asking here. > > Make it your own class which extends DB_DO and put some > > generic code in there. Then you don't have to duplicate things. > > > What does this mean? This is what you were planning below. You'd make that class and have your DOs extend it. However, I meant that you should create a toString function that would work for *any* of your DOs and have this in your extended class. Extending getLink in that way is not going to work too well. > > This is sort of how I was planning to extend getLink() to return a > custom class instead of using the factory. > > My_DB_DataObject extends DB_DataObject { > function &getLink($row, $table = null, $link = false,$class=null) > //copy and paste original getLink() code > ... > //STAR MY CHANGES > if( isset($class) ) { > $obj = new $class(); > } else { > $obj = $this->factory($table); > } > //END MY CHANGES > ... > } > } You *can* do that kind of thing, but copy/pasting code from the class you're extending is a bad bad idea. You will have to watch for changes to this function in the future and migrate the changes back into your own script. I see two options for you. 1) If your toString method is heavily dependant on the table you're getting the string for, put a special toString method in each table's class which does what it needs to do. It's perfectly fine to edit an auto-generated class as long as you leave the stuff between the autogenerated markers alone. 2) If your toString method is abstract and can be used for any of your classes, make your own class which extends DB_DataObject and defines the toString method. Then alter your auto-generated DOs to extends from it. Also, if you have several types of toString methods you could make multiple classes that your DOs could inherit from depending on which toString method they need. I strongly discourage overloading getLink as it's an internal DB_DO method and shouldn't really be messed with in that way. If you're going to do it anyway you may want to call parent::getLink then make your object and copy the fields from the one you got from the parent into it. But, again, I discourage this. > > Thank you for the quick response... > -- Justin Patrin