Symfony 2.0 vs Agile Toolkit 3.8 – part 4 – Bundles, Users, DB

Wednesday, May 19th, 2010|Misc|by Romans

This post continues comparison of Agile Toolkit and Symfony 2.0. This post is based on features described in Quick tour – page 4


This is a new concept for Agile Toolkit introduced in 3.8. It is however called “Locations”. Everything in Agile Toolkit is not bundle, but rather a resource of particular type. Resource may be found in one of the locations.

In practice we have to deal with many cases, when framework change might be required or extended locally. We might then copy ./lib/Form.php from ./amodules3/Form.php and tweak it. The includes work, they will grab local copy of the file for auto-inclusion if it exists first. The same thing applies to templates, javascript routines, css and images. Through this approach you can drop image under template/jui/images/logo.png and it will automatically used instead of the one bundled with the theme. This is calling substituting.

Third party bundles will play major part, however we have to implement them without hogging performance. Currently you can manually specify additional locations.




Common practice on substituting

Often your code snippets will rely on common class such as Page, but you will want to implement to tweak it for your project. In 3.8 a common practice is to create proxy classes in lib/* such as MYPage, MPForm, MPGrid (where MP is project abbreviation). However we do plan to use “Page”, “Grid”, “Form” as a proxies to Form_Generic, Grid_Generic etc and use substituting technique to override those within your project.

User attributes (sessions)

In Agile Toolkit any object may use $this->memorize() , $this->recall() and $this->forget() to safely store data in session. If you want multiple objects to use same data, use $this->api->memorize()

It’s discouraged to use sessions for things like notice requests – after all you have to keep in mind that in web app you may have multiple browsers open, ajax requests firing and then user still have that “back” button. Web is designed state-less and should stay this way.

memorize() is used to save state of certain control if user leaves the page and comes back. For example, grid will use memorize() for the sorting order. Once you log out it’s gone, but while you work with the application it will remember how you sorted the grid on each screen. Filters will also memorize their contents until you reset them.

Accessing the Database

Agile Toolkit takes much more responsibility in a way how user accesses database. Of course you can still send requests through $this->api->db->query(), but in practice it is never used.

Instead framework provides you with db->dsql() which will return a stand-alone class. The class called dynamic query. It’s similar to queries in Zend framework, however implementation is much more powerful and allows to do updates, deletes, inserts and can potentially be extended for other operations.

A common use would be



// no product exists


dsql() is simply a query building engine. You can use dsql->select(), dsql->update() to generate a safe SQL code, in case you want to use fetch(). Agile Toolkit always relies on dynamic queries – all objects. This allows you to have a code like this if($_GET['q'])$grid->dq->where(‘name’,$_GET['q']); Framework will encode element properly. Query used by the grid will be altered only if argument was passed. Notice that you can also do joins, grouping, ordering and more.

Sending emails

Email parser relies on functionality of SMlite template engine and provides a easy-to-use wrappers. Often mail body will be stored in the text file and in many cases it will be supplied in both text and html.

When you use TMail, you use set() to define to, from, and as well as signature, and parts of the message body. The whole class tries to fit requirements of a modern web app out of the box, while remaining quite simple and transparent.

Read Part 5 for Agile Toolkit comparison with Symfony 2.0