Symfony 2.0 vs Agile Toolkit 3.8 – part 2 – The View

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 2

The View

In Agile Toolkit, View is a class you can occasionally add to your pages to implement all sorts of things. There is also AbstractView class, which defines support for templates, spots and rendering. So what Agile Toolkit calls View is slightly different to Symfony.


As I mentioned in my previous post – Agile Toolkit comes with a really simple to use templates. A template looks <?_content?>like this<?/?>. Regions can be nested and can be empty. You can then manipulate them through $template->set(‘_content’,'like that’);

The reason <??> tags were selected for templates is for compatibility with html editors. We do not want designers to tinker with the PHP-code. Agile Toolkit project are developed by teams. Sometimes tags are added by designer but most commonly developer adds them into the template. Our goal was not to disrupt the look of the template and preserve consistency as much as possible. Slots (or spots) will not have impact on a final rendering unless they are re-assigned in PHP.

layout.php would commonly be stored in template/<skin>/shared.html and it becomes a default template of the API. Usually the shared.html will also contain some sample content inside <?Content?> slot – which will always be replaced by the page contents, but can sit there in the template regardless.

When we are referencing templates we usually also define “top tag”. This practically allows you to copy shared.html into page/hello.html, then use array(‘page/hello’,'Content’) as the template for the page. It will ignore anything around the <?Content?> slot. Again – this allow you to preview / edit template in native editors. This approach was implemented long before HTML editors learned to deal with template inclusion logic.

Template inclusion

In Agile Toolkit templates do not carry any logic, however should you need to include templates, you do this; $page->add(‘View’,null,null,array(‘outter_template’,'_top’)) -> add(‘View’,null,’slot_in_outter_template’,array(‘inner_template’,'_top’));

By default when you add object it uses Content slot and it will default to use template inside that slot. This allows you to define multiple objects which will re-use parts of the same template. Should you re-implement your Menu class with Menu/SubMenu – they both can use compatible template syntax.


There are no way to specify actions to the templates directly. They make things very complicated, especially when you have slots inside the regions which is have action applied. There are implementation of formatting in Grid cells. You can also use $template->eachTag(‘mytag’,function($t){ return ‘<b>’.$t.’</b>’;}); (or any other callable as 2nd argument).

Links between pages

In a very similar way to router->generate, we produce links through $this->api->getDestinationURL($page,$args); There are however a catch – this function returns URL object, which renders into relative URL by default, but can be further manipulated.

The function however will not look or try to fine-tune URL based on routing, but will simply encode arguments. Another important thing it does – inclusion of Sticky GET arguments. This is useful, when you are editing record, the ID becomes sticky so all the links generated with-in the page will carry the ID automatically.


Instead of separate classes for assets, javascripts and stylesheets we are using single PageFinder class which defines $api->locate. So a similar syntax would be $this->api->locateURL(‘template’,'css/blog.css’); We have no distinction between stylesheets and other template components (but we are likely to add). However we do separate javascript libraries.

The same location logic is used for php files, mail templates, log directory, etc. User can also extend by adding and looking for his own resource types.

JS and CSS Helpers

Agile Toolkit have two classes for JS – jQuery and jUI. They are – like many things – optional. Use $api->add(‘jUI’) to initialise.

You can use $api->jquery->addInclude() or $api->jquery->addStylesheet() for a similar functionality. Behind the scenes there will be a check to physically locate the files, then convert them into proper URL location. Once you use those functions, they will be properly included in your rendered page.

jUI is superior to jQuery – if part of the page is being loaded through AJAX request which requires additional JS or CSS file to be loaded, it will use be able to include it dynamically.

In practice, Agile Toolkit usually uses the following syntax


This will properly take care of JS dependencies, load plugin dynamically if required and pass options to the tipTip initialisation. Please note that the line above does not require you to write any extra PHP code to support tipTip plugin.

Agile Toolkit have no generic implementation of JavaScript. It was removed in favor of jQuery and jQuery UI, however should you want to use it – you can probably bake something up and use your engine instead of jQuery.

Agile Toolkit also comes with some JS libraries for jUI, which will take care of many things. Integration with jQuery/UI in Agile Toolkit is the most complete I have seen across all the frameworks.

Final Thougths

Agile Toolkit tries to approach templates in a more out-of-the-box fashion. In a common project you might not need to touch templates at all. We respect and separate designer and developers and how they interact with system. This also allows you to encrypt your PHP code while leaving templates out there. In practice this worked out really well and there is hardly any need for template actions.

From the Agile Toolkit 4 we plan to make our SMlite engine replaceable and roll-out an alternative implementation based on native XML / DOM parsing in PHP. The implementation of the applications in Agile Toolkit makes it possible to easily substitute template engines with very minor impact on other parts of the code.

Also Agile Toolkit approach allows you to have skins. Same business logic on top of several completely different templates. In symfony you are limited to CSS manipulation as HTML is wired up with part of the business logic.

Read Part 3 for Agile Toolkit comparison with Symfony 2.0