What is Active Record?

Active Record pattern have been hugely popular due to adoption in Ruby on Rails and in other frameworks. (Active Record explained on wikipedia). Typically a class is generated based on the database table schema. All the fields of the database are reflected as properties of the model. Class has several constructors allowing to load model directly by ID or search for records. Only one record can be loaded at a time.

Why Classic Active Record is Broken?

No Testability

When the object is created, constructors does not accept reference to the database engine. Instead, they manage to pull it from some global namespace. That makes it very difficult to use Active Record with multiple database configuration or for testing.

Static methods / Constructors

A static method of a class which creates new instance of that class is called “constructor”. With Active Record there are multiple constructors present which can load record in a different ways. Number of constructors depend on the table structure in some implementation such as loadByCode() would only be applicable if “code” field exists.

Abusive properties

Potentially table can contain any field therefore model may have no “reserved” properties. That makes it virtually impossible to build any decent logic in the abstract model class.

Code generation = duplication

I am always amazed how same people preach about code re-use and how awful it is to copy-paste your code and then use code generators which effectively build thousands of lines of code for them. It might look good in your versioning system, but it is a very bad development practice.

One table = one class

While frameworks typically allow you to specify “parent class” in the YAML definition, in practice it is rarely used. We know that sometimes one table may contain different entity types, but Active Record implementations does not help in separating them into different classes.

Operations with multiple records

By definition Active Record object can hold one record only. If you need to iterate through multiple records you will end up creating and destroying objects, which introduces performance overheads.

Lack of conditioning

Active Record typically allow to load ANY record present in the table. It’s virtually impossible in many implementation of Active Record to restrict loading to certain types of data. That is, for example, implementation of soft-deletion. Implementing it often is a major effort.

Recipe for an Improved Active Record

Dependency Injection

There might be many variables model may require. Database driver object is one thing, but it might also require some other information. Specifying multiple objects for constructor is troublesome and inconsistent. My suggestion is to specify just one object which contains links to other necessary resources.

This object can be passed through the factory class. I have solved this problem having each object carry reference to such an object and whenever new object is created, it also receives that reference. That is a “api” class which can be used to reference database connection: $this->api->db. In practice, there may be multiple API classes, which makes it possible to inject dependency into any object.

Avoiding Constructors

If a model object could have a state where it is not associated with the database record, then the same object could be reused multiple times. If object is created first and then load() method is used to load new record from database then it can be subsequently called to add more records without the need to create model instance every time.

That means other methods can be used for loading data. As developer you may define new methods for data loading in your model classes which would override default methods.

Avoiding using properties for fields

In a database one field usually is a primary key. In most cases it’s called “id” but not always. If we want to introduce a property in our model, which will always refer to this primary key it may clash with non-primary key in a classic implementation of Active Record.

Fortunately PHP objects can also act as arrays. By using $model['name']=’John’ the requests can be easily routed and saved inside internal array without polluting all of model property namespace. The $model->id then can always contain value of record’s primary key. Other operations are possible through methods set() and get(). $model->set($array);

In this implementation other model properties can be used internally by model business logic without affecting any fields.

Avoid Code Generation

Now that we have freed up properties of the Model class, we no longer need code generation. In fact we can configure model fields through PHP and store more meta-information for each field.

Not only that, but adding fields dynamically is now possible by using addField method. Native PHP calls are faster then using PHP to parse other file format. Native PHP is also more powerful and can allow you to define fields much more flexibly.

One table = Many Classes

Now we can inherit our models and add additional models and change behavior for the newly created classes. No longer there is one-to-one relation. You can also remove some field definition in your sub-classes if the field is not used for that business case.

Now you can create models for “User”, “Admin” and “Moderator” based on the same code-base and the same database table. Moderator, however, would have more methods/actions and might as well be able to address more fields in a table.

Ability to extend Models is a powerful strategy. It allows you to leave your existing code intact, but add a new model for your new use-cases. This greatly helps you to reduce amount of testing you need to perform after structural change of your database.

Operation with multiple rows

Now that the active record object have a state with no data, it can also be used as iterator through multiple records. What is great about our implementation is that for each iteration we simply need to load data from PDO into our internal array.

But let’s also add ability for a model to have conditions, which are automatically applied when loading data. By using conditions you can narrow down the selection of a model. Some models can even have default conditions, such as “Admin” model would only iterate through records with is_admin=”Y”.

Full Conditioning

With the availability of transactions, we can now insert record into the database and then attempt to load it. If existing model conditions will let record to be loaded, then it was saved properly. Otherwise the newly saved model does not conform to the conditions and transaction must be canceled.

With this the model of “Admin” can no longer save non-admin users into the database. Full conditioning now gives us a great assurance that any widget, piece of code or any developer working with Admin model would have no way to bypass some of the restrictions.

What’s even more valuable in SaaS applications is the ability to introduce condition based on a currently-logged-in user. Removing the need to always check for record author and having it done automatically is a great piece of mind for the security focused people.

Agile Toolkit delivers Improved Active Record Approach and more

Model implementation in Agile Toolkit offers all of the solutions described above and much more including Joins, Expressions, Traversing and Behaviors. Found out more: http://agiletoolkit.org/doc/modeltable

Read More…

Or

Watch Presentation Slides…

This release is the result of a half year effort and is based on the feedback we have received on 4.1 version. It brings a lot of improvements and enhancements but the primary goal is to create a fully transparent and fully-documented underlying architecture and promote extensibility through add-ons. The syntax of a new version is compatible with 4.1 with some exceptions outlined in our upgrade notes.

If you are new to Agile Toolkit — follow to our interactive introduction.

New Data Model

Agile Toolkit have always had a powerful ORM manager, but the Active Record support was lacking. With 4.2 the base classes for Models and Relational Models are completely rewritten. The new structure is much more extensible and efficient. The syntax has been simplified considerably.

The Agile Toolkit have been well received in the small companies and with new release it now targets medium companies. Support for variety of relational databases now includes SQLite, PostgreSQL and can be extended very easily for any database supported by underlying PDO architecture. Agile Toolkit now also have a set of models which can be used with no-SQL databases, caches and transparent APIs.

Support for additional databases, techniques and protocols will be coming through add-ons.

New CSS Framework

Although the interface retains the similar look, the underlying CSS framework is now much more powerful. It’s been re-writen using lessCSS and is based on 12-column grid system. CSS classes are much easier to use and build your interface with. The alteration of the look can also be easily achieved, things like line radius, spacings, number of columns, footer behavior can be very easily changed through a very simple CSS configuration file.

New Add-on architecture

With the version of 4.2 minimum requirement for PHP is now 5.3. That enables the use of namespaces. With namespaces developing add-ons for Agile Toolkit is pure enjoyment. You will find a add-on developer guide on our documentation site, but what’s really important is that your add-on can rely on core user interface, other addons and contain both the library and UI elements. This makes it possible for addons to be quite awesome. Developer of payment gateway can now provide developers with the actual payment form instead of set of functions written in the low-level PHP.

Fully Documented

Agile Toolkit is coming from a closed-source environment. It was initially designed to be used within our web development company: Agile Technologies. We have open-sourced our Agile Toolkit in early 2011 but it is only now that the documentation have matured enough for wide adoption.

Become Agile!!

For all web developers either freelancers or working for the companies there are many reasons for using Agile Toolkit in your next project or in your company. If you need to look at some project examples, here are some example sites launched recently and built completely in Agile Toolkit. If your project has already started why not:

• develop Administrative Back-end using Agile Toolkit to save time.
• re-build your model structure on Agile Toolkit ORM and improve security.
• use Agile Toolkit for serving static pages and improve speed.

If you are in the need of custom web development using Agile Toolkit, consultancy, training or add-on development — our experienced team can offer you great solution (we are now based in London, UK)

We are hiring!

Are you looking to join a great team to join which values great software design and your artistic programming skills? Would you want to collaborate as a part-time freelancer or a full-time employee? We have some great employment offers and real projects you can join. Contact jobs at agiletoolkit.org.

https://groups.google.com/forum/#!forum/agile-toolkit-devel

You can learn a lot buy learning fundamentals of Agile Toolkit.  I’m starting from the very bottom layers of the framework, so join in quick!

Unless you want to reinvent the wheel, you should look into using some AJAX / PHP library. Agile Toolkit amongst other can be a great help when you want to build interaction between JavaScript and PHP.

JavaScript event to trigger PHP function

Before going into AJAX, here is how you could produce random numbers in plain JavaScript:

<button id=”mybutton”>Click Me</button>
<script>
$(‘#mybutton’).click( function(){
$(‘#mybutton’).text( Math.random() );
}
</script>

Agile Toolkit comes up with an elegant way in PHP:

$mybutton=$this->add(‘Button’)->setLabel(‘Click me’);
if($mybutton->isClicked()){
$mybutton->js()->text( rand() )->execute();
}

See this example in action

More information of Binding JavaScript actions to PHP

Code achieves same result, but the “Rand” value is calculated on the server. This code relies on the JavaScript function “ajaxec()” defined in JavaScript Utility library (Universal Chain).

How to make it even better?

Wouldn’t it be even greater if you could bind any action to any object like that?

$this->add(‘H3′)->set(‘Move mouse over’)->on(‘mouseover’, function(){

$this->js()->text(‘Thank you’)->execute();

});

Subscribe to my channel on YouTube to see the screencasts as soon as I publish them.

The first 6 one-hour sessions is about creating a simple Task Manager. Many thanks to Maurizio for his participations.

Screencast with me!

If you’ve got Skype and great idea for Agile Toolkit we could help each-other. I can help you move forward with your idea and I would get a material for a new screencast session. Please use contact form to send me your ideas.

• 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.

if(!$model->loaded())$model->load(3);

Models will also support proper joins in which you could define how new entries are being added.

The way how Models interact with Views and Controllers will be different. Currently $view->setModel(‘abc’) initializes controller first and then initializes model. In 4.2, model is initialized first and placed inside $view->model() and then controller is initialized which imports fields into a form or grid. As a result, you will be able to use Models with “Form” and “Grid” classes, without the need for “MVCForm” and “MVCGrid”

This makes it possible to do many really interesting things for example create Form presenting fields from multiple models.

Also “reference” field is no longer needed as models can be used with “dropdown”.

SMLite improvements

The implementation of our Template Engine is really old but works well. It relies on explode()ing string into chunks then iterating through them. The new SMlite implementation will rely on regular expressions and will perform faster. Currently there are some technical issues with regular expressions, but I hope to overcome them before next release. There will be no new features for the template engine, I intend to keep it simple.

Other improvements and Debug

Overall the migration to use exception() method for raising exceptions proves to be quite rewarding. Errors now contain more useful information and are ready to be localized.

While in debug mode, it will be possible to extract additional information from your current errors. For instance if exception is raised inside Model, it adds a link to error message allowing you to reload the page with model’s debug enabled. This way you don’t need to add $m->debug() manually to spot the problem.

Additionally debugger will allow you to dump a complete tree of all the objects in the system highlighting the problem branch which produced an error.

On the user-interface side, the started installation of Agile Toolkit will feature a simple “inspector” so that you could visually see and understand your code as you start with Agile Toolkit, very similarly to http://codepad.agiletoolkit.org.

Changes into atk4-addons

I plan to discontinue atk4-addons repository and instead make those addons loadable and installable through a web interface. The initial package of Agile Toolkit will allow you to browse addons library and install them individually with a mouse click. Addons would be installed into atk4-addons folder.

Documentation and Testing

One of the reasons why DSQL, SMlite and Models are currently lacking in documentation is because I am not satisfied with their internal implementation and was planning to re-implement them for 4.2. I am planning to have our own “Documentation Viewer” and “Testing Engine” as downloadable add-ons as well as having the documentation available for you in off-line format as some users have been requesting.

More importantly you will be able to enhance documentation and test scripts with your own as your application grow in scale.

Conclusion

I’m looking forward to the 4.2 release this winter. As I have already mentioned, Agile Toolkit release cycle produces new major version once every half year. The version is compatible with previous release, however if you do run into some compatibility problems you can still use old TMail, SMlite or DBlite/Models.

Throughout the minor releases any changes are backwards compatible with the use of “Contoller_Compat” class.

Many thanks for your continued interest in Agile Toolkit and I hope you are as excited about new changes as I am.

I first have learned about Object Oriented in the age of 10, in 1990. I have already mastered BASIC and was exploring the world of Turbo Pascal. My young mind couldn’t grasp the ideas of in capsulation and polymorphism so I asked my mom to help out. She took the book and carefully kept re-reading the introduction.

“Objects. Think Objects”.

Years later I have been eager to apply the Object Oriented principles everywhere: the games I wrote, the demo-scene productions, my copy of multiplayer user dungeon. When I settled in as a Web Developer and learned PHP3.0 I was disappointed at the poor implementation of the objects.

The birth of Agile Toolkit was as soon as the Zend Engine 2.0 alpha was released. I started to re-wrote the framework I had into a new, powerful language. From the first versions the most important distinctive feature of Agile Toolkit today have been embedded into the very core of the framework.

Rendering of the Runtime Object Tree

2-3 decades have passed since the concept of Object-Oriented User Interface have been launched on the desk-top computers. The realization that the elements you can see on your screen have many similarities even through the look differently defines every Graphics User Interface today. To understand this concept Imagine a “button” and a “input field” next to each-other.

Here a two object quite distinctive in their appearance are being rendered by the operating system by calling each object’s rendering function. The system may decide to force objects to re-render or skip rendering if they are not actually visible on the screen.

The exactly same idea is in the foundation of Agile Toolkit. Because I have been creating my own User Interface in Pascal and Assembler this was to me the best possible solution to interfaces in the Web Applications – implement them as a tree of visual objects generated during the run-time of your application and then rendering the necessary components.

Making Interface More “Webby”

Initial implementation of Agile Toolkit was only good to produce back-end administration systems as it was too in-flexible to do the requirements of the creative minds of our web-designers. Many UI Frameworks are destined with the same interface style, but Agile Toolkit was able to introduce a great breakthrough.

All the objects in Agile Toolkit, no matter how complex, are producing a valid HTML code based on object templates. This approach allows to easily change HTML behind individual or all objects and finally produce the great solution for website front-ends. However the default look and feel of Agile Toolkit application gives developers a great start.

Progressive Enhancement

By the time Agile Toolkit has matured the move towards Progressive Enhancements in CSS and Scripting made it possible to create a separate JavaScript layer which would  be optional for the elements. While earlier we would need to set “onchange” and “onsubmit” handlers into HTML baking templates extremely complex, now all of the JavaScript code have gone into a separate JavaScript API based on top of jQuery UI.

This allowed to purge all the JavaScript hacks from the code and rely on a much more powerful Object-oriented interface between JavaScript and PHP.

Business Logic

With the increasing complexity of our projects, it became apparent that a Objective Model layer is necessary. It finally appeared in Agile Toolkit in 2008 as an optional component. The models in Agile Toolkit serve a different role than the Models of other ORMs and Frameworks. Instead of only offering DataBase engine transparency and populating classes from data structures models in Agile Toolkit introduce a new dimension to modeling – inheritance. You can understand the power of this when you can narrow down values in the drop-down field by simply setting the right model to the reference definition. SQL Databases could not implement such flexibility but a PHP framework can.

RoadMap for Agile Toolkit

Up till now, Agile Toolkit had been walking a different path than other frameworks. Their goal was to provide developers with “utility” or a wrench to do certain things better. Approach of Agile Toolkit is to build levels of abstractions from the very bottom up. I must admit, that I can solve any web-related task with Agile Toolkit, but if I must produce a solution in clear PHP I feel lost and confused.

The immediate road-map for Agile Toolkit is to improve the 3 strengths it has by making it easier to interact and build. The “Model Builder” is in the works, which provides a visual interface to building new model fields and actually generating a PHP file as a result. The syntax of Models is already extremely simple but it will be even more so with the builder.

Another initiative is the User Interface builder. This allows create pages and add objects on your pages with a drag-and-drop interface. Similarly the tool would be capable of outputting a valid PHP code you can then further modify.

The number of Views and Templates will be made available through an on-line repository. In a way this would be similar to WordPress extensions, but tho time you will be installing classes which will aid you in building an Interface. The available views could be either free or paid creating a possible new revenue model for developers. A good example for such an view would be a “Gallery”. You could add this to any application you’ve got and bind it with the model holding images.

Unlike add-ons in other frameworks, the unified UI, JavaScript and Model structure makes sure that the add-on you are adding will fit-in perfectly, will be easily configurable to do the job and will contain minimum amount of code.

Conclusion

I adore web applications, but today it is way too complicated to build a web application. The situation reminds me the “DOS” and with Agile Toolkit I am able to introduce a Graphical User Interface for The Web.

http://codepad.agiletoolkit.org/

One awesome tool I’ve created in the process is the right-side “inspector”. Inspector examines the current page and objects on that page looping through them and finding objects which were added by the example. You can then mouse-over the objects to highlight the objects on the page or click to see source code of that class.

Enjoy all the examples and I plan to add more examples (from http://demo.atk4.com/) soon.

Download and Install Codepad

Would you like to look further into how codepad works? You can get it from github:

git clone git://github.com/atk4/atk4-codepad.git
git submodule init
git submodule update

Add your own examples into page/* to share them with your friends. You can also “fork” codepad and push back some of your own examples if you would like to see them in the Codepad.

One of the best qualities of Agile Toolkit is that it can be very nibble when you want to use it to fill the gap. So let’s scrap the whole page routing mechanics and simply create a SINGLE PHP file which would work on it’s own. For this, you will need to have most up-to-date Agile Toolkit (4.1.3).

Download “Agile Toolkit” and un-pack in the temporary directory. Copy folder “atk4″ into your wordpress directory.

Next open file test.php inside your wordpress and type the following:

<?php
include 'atk4/loader.php';
$api=new ApiWeb('sample_project');
$api->add('jUI');
$api->add('H1')->set('Subscribe to Newsletter');
$form=$api->add('Form');
$form->addField('line','email');
$form->addSubmit('ok');
if($form->isSubmitted()){
$em=$form->get('email');
$form->js()->univ()->alert('Thank you for subscribing, '.$em)->execute();
}
$api->execute();

If you open this file in your browser, you’ll see a form with a field. You can now refer to samples on agiletoolkit.org site to customize or even create your own theme, but pretty much any code should work for you.