PHP Pear - Re: [PEAR] DB_DataObject Can getLink() return child class of DB

Author

Re: [PEAR] DB_DataObject Can getLink() return child class of DB_DataObject

Justin Patrin

2005-03-31, 8:57 pm

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. Make it your own class which extends DB_DO and put some
generic code in there. Then you don't have to duplicate things.

--
Justin Patrin

Ben Ford

2005-03-31, 8:57 pm

Justin Patrin wrote:

> On Thu, 31 Mar 2005 14:55:24 -0800, Ben Ford <ben@naturestears.com> wrote:
>
>
>
> 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.

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 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
...
}
}

Thank you for the quick response...

Ben Ford

2005-03-31, 8:57 pm

Justin Patrin wrote:

> On Thu, 31 Mar 2005 15:25:57 -0800, Ben Ford <ben@naturestears.com> wrote:
>
>
>
> That's outweight. ;-)
>
> I'm not sure what you're asking here.
>
>
>
>
> 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.
>
>
>
>
> 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 agree. This is a bad solution.

> 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.
>
Yes, I was originally trying not to edit the auto-generated classes. (I
am using PHP 5 objects and the auto-generated are PHP 4 style. I suppose
I didn't want to mix syntax and it I wanted to use PHP 5. In the end,
who cares though.)

You have made it clear to me that putting my table related code into the
auto-generated classes is the "correct" way to go.

If I do this, my problem will be solved. I can see my current method is
very bad!

> 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.

I agree, it is a horrible idea.

>
>
>
>
I appreciate your feedback!

Ben Ford

2005-03-31, 8:57 pm

Justin Patrin wrote:

> On Thu, 31 Mar 2005 16:00:15 -0800, Ben Ford <ben@naturestears.com> wrote:
>
>
>
> Regenerate them. The newer versions of DB_DataObject will use PHP5
> syntax when you use the generator in PHP5. :-)
>

Perfect! I thank you for your time!

You have saved me from several mistakes and, I learned a bit more how to
use DB_DataObject correctly.

Sponsored Links