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

[Paul M Jones]

Hi all,

I've started a new Solar development branch called "model"; you can  
see it here:

   <http://solarphp.com/svn/branches/model/>

The idea is to start developing something along the lines of the Ruby- 
on-Rails "ActiveRecord" class.  Of course, it can't actually *be* as  
good as ROR's implementation, simply because Ruby allows a lot more  
magic than PHP does.  You can see the new classes here:

   <http://solarphp.com/svn/branches/model/Solar/Sql/Model.php>
   <http://solarphp.com/svn/branches/model/Solar/Sql/Model/Record.php>
   <http://solarphp.com/svn/branches/model/Solar/Sql/Model/ 
RecordSet.php>
   <http://solarphp.com/svn/branches/model/Solar/Sql/Model/ 
DataFilter.php>

It is a work in progress, but the intended usage is similar to that  
found in Rails and Cake.

* Reads the schema from the database, creates the schema if it  
doesn't exist, and keeps the schema in a cache if one is available  
(to minimize database hits).  This means you won't need to define  
$_col beforehand, you can just point the Model to a table and it will  
get everything it needs.

* Uses hasOne(), hasMany(), belongsTo() to define relationships  
between tables.  (Has-and-belongs-to-many is not ready yet.)  Allows  
for eager loading of to-one values via automated joins, and lazy- 
loading of to-many values on demand.  Also allows for custom-defined  
table names, foreign key names, WHERE and ORDER conditions, etc.

* Extensible filtering methods internally to automate validating and  
sanitizing for common operations (validateUnique, validateConfirm, etc).

* Custom per-model Record, RecordSet, and DataFilter classes, with  
fallback through the hierarchy (as with View helper plugins).

* Single table inheritance to keep data for similar classes all in  
one table.  Think of the Nodes table as it is now: when you read from  
the Nodes model, you can get back a Bookmarks object, or a Comment  
object, or something else, based on the value of the "type" column.

* Automated serialize/unserialize of user-defined columns, so you can  
keep arrays and objects in the table.

* Use of auto-increment instead of sequences (although this is a big  
break from years of habit for me).

One major difference between the Solar implementation and the Rails/ 
Cake implementation is that the Model class refers to table; a Model  
return one or more records, which refer back to their Model for their  
behavior.

     // object to work with the Nodes model
     $nodes = Solar::factory('Solar_Model_Nodes');

     // get a single record from the model
     $node = $nodes->fetchOne();

This is for a couple of reasons, the main one being that PHP doesn't  
support something called "late static binding".  Otherwise we'd be  
able to a single Model class instead of Model/Record/RecordSet:  
static Model would be for methods for table interactions, and  
instance Model methods would be for the current Record (as with Rails).

The work is nowhere near complete, esp. when it comes to save() and  
related objects, but it's good enough to start talking about and get  
feedback on.  Let me know what you think.



--

Paul M. Jones  <http://paul-m-jones.com>

Solar: Simple Object Library and Application Repository
for PHP5.  <http://solarphp.com>

Join the Solar community wiki!  <http://solarphp.org>

Savant: The simple, elegant, and powerful solution for
templates in PHP.  <http://phpsavant.com>