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

[Andreas Ravnestad]

Paul M Jones wrote:
> Not quite what I had in mind; I'm thinking more along these lines:
>
>      // model for all blog posts
>      $posts = Solar::factory('EnterpriseCompany_Model_Blog_Posts');
>
>      // get a single post by its primary key
>      $post = $posts->fetch(1);
>
>      // set a title on it
>      $post->title = 'Solar pwns the competition again';
>
>      // save it
>      $post->save();
>
> To more closely match Rails, you would do something like this:
>
>      // model for all blog posts
>      Solar::loadClass('EnterpriseCompany_Model_Blog_Posts');
>
>      // get a single blog post by its primary key
>      $post = EnterpriseCompany_Model_Blog::fetch(1);
>
>      // set a title on it
>      $post->title = 'Solar pwns the competition again';
>
>      // save it
>      $post->save();
>
> We have the modified step for getting an instance of the "master"  
> model object, because ROR's ActiveRecord doubles as the TableModule  
> *and* the DomainModel. PHP can't pull that off yet, because static  
> methods don't have access to things like the extended class name.
>
> The Record object returned by fetch() carries the all the needed  
> data, and has a tie back to the Model class that generated it. That  
> means it knows which data key is the primary key, which is the  
> inheritance type, etc. Record::save() passes its data back to the  
> bound Model::save() method, which does all the heavy lifting  
> (including domain logic) and reports results back to the Record.
>
> In many ways, it's like the current Table/Row/Rowset interactions,  
> but with better/more-extensible filtering, relationships, etc.
>
> Does that make sense at all?
>   


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 :)

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

So should the business logic go into a subclass of 
Solar_Sql_Model_Record? That makes sense, but then I'd have to modify 
_recordset_class in my subclass of Solar_Sql_Model, as well as creating 
a subclass of Solar_Sql_Model_Record to implement my business logic in. 
Oh and that also means two subclasses per model. Yikes. Wait, maybe not 
necessary to subclass Solar_Sql_Model though. Hmm.

Anyway, by business logic I do not only mean things like filtering and 
validation (which you seem to have taken care of), but also anything you 
can think of to put in a domain model. For example, for an image model, 
it would be very plausible to add a method to generate and save 
thumbnail previews. I guess my question is this: where will this method 
go? The subclass of Solar_Sql_Model, or the subclass of 
Solar_Sql_Model_Record (if any)?

Or, for a User model, it would be very plausible to add logic for 
complex authorization arithmetic. Or possibly unlink() a File model from 
the file system. And so on, I'm sure you see what I mean :)

-AR