Symfony 2.0 vs Agile Toolkit 3.8 – part 4 – Bundles, Users, DB
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.
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.
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.