Thinking about improved implementation of Model/Table..

The way how the current Models/Controllers work it makes it quite difficult to flexibly manipulate them. When I am working with grid, I can specify controller, but only one. (through setController). I was thinking about a better way of implementing this. This is what I came up with.

[php]
$g=$this->add(‘Grid’)
$g->importFields($model,array(‘field1′,’field2′,’field3′));
[/php]

Second argument can be omitted. How is this different? Well importing fields would be the primary concept throughout the whole model system.

Let’s define some example. Define model for person:

[php]
$person=$this->add(‘Model’)->setSource(‘person_table’);
$person->addField(‘text’,'name’);
$person->addField(‘text’,'surname’);
[/php]

(general idea follows ATK patterns)

Now that the model is defined, we can build a grid based on this model.

[php]
$g=$this->add(‘Grid’)->importFields($person);
[/php]

However this works with wide range of cool things. For example my dsql could actually work with models.

[php]
$dq->join($person,’id’,'person_id’);
[/php]

DQ will automatically take care of database name collisions and will properly name fields. Secondly you can import fields from one model into another.

[php]
$worker=$this->add(‘Model’)->setSource(‘worker’)
$worker->importFields($person,’id’,'person_id’);
$worker->addField(‘money’,'Salary’);
[/php]

Worker now contains fields from 2 tables, however it will be smart enough to properly include joins into query only if those fields are requested.

[php]
$g=$this->add(‘Grid’)
->importFields($worker,array(‘name’,'surname’,'salary’));
[/php]

In this case search for name and surname is performed against worker first, but because worker does not have those fields defined, other models are checked.

Implementation of calculated fields becomes really trivial as well. When we add new field, we can define how it should be calculated.

[php]
$worker->addField(‘text’,'full_name’)
->setSQLQuery(‘concat(person.name," ",person.surname)’);
[/php]

this would allow us to specify what is added into query when field is used. Of course maximum flexibility can be achieved if you use your own class for model field. This way you can define, what modifications with the query must be performed in order to add field into the query.

Model would work as a proxy between View and data source (dsql) during data query. It can further filter results through standard implementation of PHP iterators. This also makes it very easy to use in the code.

Let’s list all workers first.

[php]
foreach($worker as $data){
$workplace->increaseSalary($data['id'],500);
}
[/php]

Multiple requests can be performed. For individual record access, we can implement syntax like this:

[php]
$me=$worker->load($id);
$name=$me->get(‘full_name’);
[/php]

Important functionality of models right now is implementation of custom functions to perform specific operations. This is easily done by extending ‘Model’ and defining additional methods.

Another good feature of this approach is independence from SQL. Through the use of setSource inside models it should be possible to engage with other media.

[php]
$worker->setSource($simpledb);
$worker->setSource ($stored_procedure->setArguments(..));
$worker->setSource($session);
[/php]

Please comment.