OO usage in code igniter structure, Model, Controller

[eluser]farinspace[/eluser]
I am trying to get into the work flow of codeigniter and would like some practical examples. My one main question is about proper OO usage within models/controllers (please forgive me if im just being dense and the answer is just staring me in the face) ...

Basic example (outside of codeigniter)

Code:

$link = new Link($db,55);

$link2 = new Link($db);
$link2->title = 'link title 1';

$link3 = new Link($db);
$link3->title = 'link title 2';

$link->append($link2);
$link->insert($link3);

echo $link->title;
echo $link->description;

$tree = $link->get();
var_dump($tree);

All the codeigniter model examples I've seen, seem to be more on the concept of a "manager" pattern, instead of managing single objects and having them interact with one another ...

Code:

// inside a controller function

$this->load->model('link');
$this->link->appendLink('link title 1',55);
$this->link->appendLink('link title 2',55);

$title = $this->link->getTitle(55);
$desc = $this->link->getDescription(55);
$tree = $this->link->get(55); // gets tree starting at this links ID/level

Lets say I wanted my model to return an object, how does the model go about creating an instance of another model/class (possibly passing an initialization parameter, and using existing db connection) and returning that object ... all with in the codeigniter framework?

[eluser]m4rw3r[/eluser]
The best way to get OO interaction with the database in CI (without writing it yourself) is to use one of the ORM tools available.
Mine is one among them (IgnitedRecord, link in my signature).

That about creating a instance of an object, just do it as you do in normal PHP, CodeIgniter is "just" a framework (but an awesome one ).
Model example:

Code:

// in a model

// almost right after <?php if(defined(...
require_once 'record_file.php';
// you can store the "record" class in the model file,
// but I personally prefer to have it in a separate file

// in a method in the model class
// this one fetches a single db row and passes the data to the Record class
$q = $this->db->get_where('some_table', array('somecol' => 'somedata'), 1);

if($q->num_rows())
    return new Record($q->row_array());
else
    return false;

But I recommend to split up the responsibilities into different parts; models handle data fetching/saving, views the displaying of the result to the user, controllers are the "glue" and uses models, libraries and views to produce a result and libraries/helpers does the rest.
I'm telling you this because it is easy to forget when you start to mix MVC with ordinary OO programming

[eluser]Colin Williams[/eluser]
There's no reason you cannot use this OOP style within the framework. Consider this model:

Code:

class Cat_model extends Model
{
   function new($param1, $param2)
   {
      return new Cat($param1, $param2);
   }

   function save($cat)
   {
      $this->db->insert('cat', $cat);
   }
}

class Cat {
  
   var $param1;
   var $param2;
   function Cat($param1, $param2)
   {

   }

}

And then a controller:

Code:

$cat = $this->cat_model->new('Calico', 'Freddie');
$cat->param1 = 'Black';
$this->cat_model->save($cat);

In my opinion, you don't really need the Cat class, unless you just want it for methods that set it's properties.

[eluser]m4rw3r[/eluser]
Umm, "new" is a keyword, use create or something instead.

Colin's example is a good complement to what I wrote above, and shows how the model can handle the creation/insertion of data objects.

btw, another reason to have the Cat class is to let it have methods that otherwise would have ended up in a helper (which would be suitable in many cases, depends on how it would be used).

[eluser]Colin Williams[/eluser]
Good points, m4rw3r. I guess I didn't come from an OOP-experienced background, so it seemed easier to catch on to CI's manager style. In all my apps, I still deal with objects, but they are typically just stdClass objects.

[eluser]m4rw3r[/eluser]
Well, the speed difference isn't big, so it does not "cost" anything to do it that way (and you also put your methods which interact with the object IN the object itself, which is a huge organizational benefit).

To be honest, I'm still a bit new to OOP and always learning .
I don't like when OOP just gets purely organizational, without any other benefit or too much speed loss (well, depends).
So I prefer a mix between the CI-style and the OOP style .

And one thing about accessor methods for object properties: Do NOT use them unless you're going to make some filtering/function calls before assigning them.
This is because you loose speed, flexibility and clutter your classes with unnecessary methods.
(and $rec->someprop = 'somestr' is shorter than $rec->set_someprop('somestr') ).

[eluser]Colin Williams[/eluser]

And one thing about accessor methods for object properties: Do NOT use them unless you’re going to make some filtering/function calls before assigning them.

Right. Given that and the fact that I don't typically have helper functions per-object, stdClass usually suffices