Re: [PEAR] 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:
> 
> 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 
> 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