As we nearing our deadline fro 4.2 release a lot of cool features have been added into development branch of Agile Toolkit such as:
- Completely new “TMail” implementation
- Completely new “DB” implementation based on PDO
- Completely new “DSQL” implementation
- Completely new “Model” implementation
- Completely new SMlite implementation
- Improvements in Site Debugging
The new implementations are functionally compatible with the 4.1 branch, although the do offer a number of benefits. In this article, I’ll highlight some of the new features about the new component implementation.
Another important feature of all the new modules is that they are are under heavy automated testing from the very start.
What’s new in the “TMail 2.0″
The TMail class actually been pushed into 4.1.3 release adds much more modularity as well as support for transports. Previously TMail would only send out emails through the mail() function, now it could be written into database, sent over Amazon SES, mail() or any combination of these.
There are also number of improvements in how TMail manages templates – it allow both HTML and Text part to be defined in your template and will automatically produce non-HTML version if you supply with the HTML only.
What’s new in DB implementation
Actually there is nothing new in the DB as compared to “DBlite”. You initialize database by calling $api->dbConnect() and it’s going to stay this way. To use the new database driver you would need to supply the “pdo” in the $config file.
DB implementation features a “query cache”, if a query is executed multiple times, it is prepared only once. This actually makes a lot of sense when you operate with models and parametric values.
What’s new in DSQL implementation
DSQL has been rewritten, but the fundamentals are the same. You create dsql() instance then call methods such as “field()”, “where()”. The new version is much more consistent about escaping arguments and handling of expressions. The new implementation completely relies on parametric nature of PDO, which proved to be a little more challenging to implement, but the interface have not been changed.
1. where(‘id’,2); // equals
2. where(‘id’,'>’,2); // explicit condition
3. where(array(‘id’,2),array(‘id’,3)); // or
4. where(‘id’,array(2,3)); // in
5. where($dsql,4); // subquery
6. where(‘id’,dsql); // in subquery
7. where($dsql->expr(‘length(name)’),123); // expressions
The new are expression and sub-qureies, and DSQL does a great job figuring out all the parametric queries as you wildly join tables. Dsql now support iterators and the following syntax is permitted:
$q=$this->api->db->dsql();
$q->table('books')->where('price<',20);
foreach($q as $row){
echo implode(',',$row)."\n";
}
What’s new in Model implementation
It has become much simpler and modular. Also I’m adding implementation of interfaces which makes it possible to access active-record in a super-easy way. Here is an example of model use in 4.2 which implements Iterators and ArrayAccess:
foreach($this->add('Model_Books')->addCondition('price<',20) as $book){
$author = $book->getRef('author_id')->sendNotification();
echo $book['name']." by ".$author['name']."\n";
}
Additionally field implementation is now implemented as number of classes, not just a single “FieldDefinition” class.
$model->addField('name');
$model->addExpression('age')->calculated(function(){ return 'years(now())-years(birthday)'; });
$model->addReference('client_id')->setModel('Client');
In all 3 cases the field is defined by a different class which defines how the field is being queried. “Model_Table” is now implemented on top of “Model” class which is a very simple implementation of a model without data-source. This base class can be further extended to allow storing model data in No-SQL storage. Caching could also be further added through controllers.
Models have also some of their methods renamed shorter. Long version will continue to work throughout 4.2, but the use of shorter version is recommended.
Truncated by Planet PHP.ie, read more at the original (another 3976 bytes)
