Symfony 2.0 vs Agile Toolkit 3.8 – part 1 – The Big Picture

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

Based on PHP5.3 – symfony 2.0 is coming soon. They provide a very good review of the cool stuff they pack in v2. I decided to write an article comparing those with similar features of Agile Toolkit 4.

The Big Picture.

http://symfony-reloaded.org/quick-tour-part-1

Download and installation

Agile Toolkit takes a different approach when it can work with virtually no extra files at all. We pack a generation script however. So create a folder, checkout atk into subdirectory and run ./amodules3/tools/admin-kickstart.sh (on unix) which will create .htaccess and main.php files.

www/ <-- your web root
amodules3/ <-- atk (could be under different name too, and can be located outside webroot)
lib/ <-- your sources
  MyApi.php 
addons/ <-- optional addons (can also be located outside webroot)
  lib/  <-- addon sources
  template/ <-- addon templates
config.php <-- default config file. 
main.php <-- catch-all
.htaccess <-- catch-all

The URL requests would be rewritten through .htaccess and main.php. Front controllers in Symfony are similar to our API concept. You can have multiple APIs, however you usually choose one for your code at an early stage and stick to it. APIs also provide less diversity, and developer features can be turned on / off by inclusion of extra classes – for example Logger.

Routing

Or PageManager is similar to Routing concept. It determines virtual path and stores it inside $api->page.

Unlike Symfony we use “pages” concept for routing, which are physical files. It allows us to include controllers optionally instead of forcing user to write controller for every single request. Pros is consistency throughout the application, however the downside is a difficulty where we can’t allow certain controllers to take care of a whole range of pages. I think both approaches provide good sense of security.

Agile Toolkit does not plan to use php5.3 implementation of namespaces and prefers to use auto-loaders, so if you are writing code, you don’t have to worry about “use”. A similar implementation of a hello world in a page would be:

class page_hello extends Page {
function init(){
parent::init();
$this->set(‘name’,$_GET['name']);
}
function defaultTemplate(){
return array(‘page/hello’,'_top’);
}

Class page_hello extends our default page class. Templates for the pages are optional however we chose to mimic symfony therefore included one. Template is searched across all the “bundles” using PathFinder. Because we map URL directly into page, we can’t support /hello/John syntax, so we are using /hello?name=John instead. This is how web software intended to be used, allows to specify multiple properties, is supported by crawlers. If /hello/John is required, you can implement this by rewriting URL into /main.php?page=hello&name=John. Seriously – mod_rewrite (especially with global config) is much more efficient in high-volume installations.

Agile Toolkit renders template by default in render() method of any View element.

A bundle concept in Agile Toolkit is loosely defined as “Location”. You can introduce new bundle and register it through $api->addLocation(‘mybundle’,array(‘js’=>’js’,'php’=>’src’,'template’=>’mytemplate’)). However we do not promote creation of multiple locations. Agile Toolkit folder itself is a single location. For each location you also define multiple resource types. There are also no plug-and-play or any meta-files which describes resource contents / properties.

Templates

Current implementation of SMlite does not treat templates as a PHP file. This is done for security and safety reasons, but also to avoid developers pushing logic into templates. Our templates use php-tags but they only define regions and spots. There are no modifiers, you can’t define in your template that certain spot must be upper-cased.

Agile Toolkit never relies on “echo”. When objects render, they pass their rendered code into parent, until Api does one full echo of the whole thing. This is done to avoid situations where you dump out some data then run into exception. Also works well when it turns out that you need to output only part of the page or use XML/RSS output at the end.

Exception is JS Chains and execute() which terminate access immediately and output javascript code.

Summary

So  to run an application in Symfony you need to set up route, controller, template and view. For Agile Toolkit you only need to define page (which can also be defined as function in API), and the use of templates, controllers and views are optional. The easiest route-to-market for Hello World application is:

1) kickstart the API

2) edit main.php to add $api->add(‘HelloWorld’); // standard View

Although in practice you most certainly would create your own Api class and use at least:

function page_hello($p){ $p->add(‘HelloWorld’); }

Read Part 2 for Agile Toolkit comparison with Symfony 2.0

3 Comments

Svetlozar Kondakov
Posted May 24, 201011:00 pm

Yeah … thats why I prefer using atk even for small and simple websites … its pretty simple and works out of the box. And though symfony also so not a lot harder to make a simple project … its one level time consuming atleast!

Zilvinas Juraska
Posted March 1, 201111:23 am

Howdy would you mind letting me know which hosting company you’re working with? I’ve loaded your blog in 3 completely different internet browsers and I must say this blog loads a lot faster then most. Can you suggest a good hosting provider at a fair price? Many thanks, I appreciate it!

Romans
Posted March 1, 201111:25 am

It is on aws.amazon.com.