[Solar-talk] Changes afoot: a new Model class

[Rodrigo Moraes]

On 2/7/07, Andreas Ravnestad wrote:
> Yes, I see clearly how it will work now. I couldn't see a save() method
> in Solar_Sql_Model_Record (I guess you haven't got that far yet), and
> that confused me :)

Hmm, this same thing same happened to me. :)

> Still, I'm not sure where the business logic goes. I'm assuming it
> should be put in a subclass of Solar_Sql_Model, but then it's (very
> strictly speaking, unless using a technique like the one I showed in my
> previous email) unavailable in the records themselves (effectively
> removing alot of the "active" in "active record").

I understand that the business logic is naturally more necessary in a
per record basis, right? From a table/rowset/row subclasses scheme
which is what we have in Solar 0.26, we go to a model/record (and
optionally recordset) subclasses scheme. Business logic go to
record/recorset. The model only takes care of the model definitions
and relationships. I'm just guessing and trying to understand.

On 2/7/07, Paul M Jones wrote:
>      // model for all blog posts
>      $posts = Solar::factory('EnterpriseCompany_Model_Blog_Posts');
>
>      // get a single post by its primary key
>      $post = $posts->fetch(1);
>
>      // see all the comments
>      foreach ($post->comments) {
>          $comment->dump();
>         echo "I belong to " . $comment->post->title;
>      }
>
> Note how they talk back and forth to each other automatically, with
> lazy-loading of to-many relationships and eager loading of to-one
> relationships.

Hmm, very very nice. I'm thinking loud that I would love this but in
many cases I would need to restrict the number of rows returned by the
child model. :) I don't have experience with these kind of models; is
paging a feature for to-many relationships on Rails or this is / will
be possible with Solar_Model?

rodrigo
-------------------------------
http://tipos.com.br