Symfony 2.0 vs ATK3.8 – part 3 – The Controller

This post continues comparison of ATK and Symfony 2.0. This post is based on features described in Quick tour – page 3

Approach to Controllers

A major difference in approach to Controllers ATK is – there are no native controllers. Don’t get me wrong, there are many classes which do similar things, but we do not distinguish them as a Controllers.

The ATK takes it’s deep root in 1999, when first version was developed. Back then the whole structure was very different to what we have now. System used to have files such as edit.php, browse.php, etc. Let’s call those – controllers. Then there were table-descriptors. Those were php-arrays which contained information about each entity. edit.php?table=user would allow you to edit users. Finally there were templates. Being 1999 it was sufficient for most administrative systems. The concept is very much obsolete by today’s standards, because it was too tied down and not flexible at all.

Delphi was one of the first languages to introduce a concept of “Resource/View”, Data provider and event handlers. I am not expert on Delphi, but I have been writing applications before then for TurboVision and early WinAPIs.

Reality is – developers back then were much more skilled on average than they are today. There were no need of MVC paradigm which usually limits you, instead the OOP was used which would on the contrary – set you free in many ways.

While many frameworks try to limit their developer – common folks and novice on average, ATK is designed to set it’s developer free. It provides a great tools, however those can be mis-used quite easily.

As a result, the MVC in not a paradigm, but a vague classification of each individual class. For instance the API itself is a both View and Controller. However it relies on the templates which contribute to the View part of it. A “LoremIpsum” class is all – View, Model and Controller. Other classes will need data provider or will require you to define extra templates.

We trust developers of ATK to make the right decisions, which will lead to a highest efficiency and best coding practices. Now back to our comparison.

Output Formats

The truth is that 99% of the output when you work with ATK is going to be either HTML or JavaScript. When it’s necessary to output data in a different format, it’s usually implemented by the respective View/Class itself. For instance you can add ability for a Grid to output XML data. ATK tries not to get into your way, but it takes another approach.

Let’s say you have developed a JS plugin which requests back-end series of XML data. You now need a frame-work to feed XML into your JS plugin. The common approach of ATK is “HTML IS XML”. Instead of inventing new communication protocols between your JS plugin and the backend – we will be exchanging chunks of HTML and JS. Obvious benefits is simplicity and compatibility. In most cases you can implement no-javascript compatibility.

When it’s required to provide different output for external resources (now web browser), then a common practice is to use a separate API. Most of the API cores in ATK are based on ApiWeb, which assumes you output web content. However you can set up your .htaccess file to redirect to a different file and use different API. In this approach the following happens in the library:

• most probably you will not need template engine. Therefore it’s not initialised. You however still can use it if you want to, but render() methods are not triggered.
• you still can access your objects, models and database. However it’s up to you to produce the output.
• you are responsible for the headers and you better to reconfigure error handling.
• ATK is not intrusive. It lets you use other framework as you see fit. By default hardly anything will be initialised, unless you use it.

Now back on web.

Request / Response

As of 3.8 ATK still does not have request filtering as a separate controller. Views and API use $_GET and $_POST directly. There are no input type hinting, however it will probably appear in ATK4. Our planned approach for get would be more like $id=$this->api->requestGET(‘id’,'int’); However despite the lack of input validation, framework have a strong output validation which keeps things quite secure.

Response is handled entirely by API. ApiWeb for instance have methods to send default headers and it will render and output template by default. ATK addresses those as a rather simple things and stays out of it.

Error Management

The concept of 404 pages is introduced by ApiFrontend. Main reason for 404 is a missing or miss-spelled file or class. Therefore if in development mode, ATK will help you to identify the problem. There are no support for HTTP errors as those are very rarely used in web applications. Primary authorisation classes have it’s own way to deal with logins, log-outs which is based on cookies instead of HTTP auth (Although there is Auth_Http class too)

Redirecting and Forwarding

$api in ATK provides with both $api->redirect() and $api->getDestinationURL() functions. You can either use $api->redirect(‘mypage’) or $api->redirect($api->getDestinationURL(‘mypage’)); the outcome will be the same. redirect() will make sure that getDestinationURL have been properly called on the 1st argument. Approach such as this allows us for more typing and better security.

There are no support for internal sub-requests, however developers can manipulate this through initialisation of multiple page objects if it’s necessary.

Note on classes

As you read through symfony examples you see many references to $this, $requset, $view, etc. It is usually not the case with ATK. There are no global variables or global constants with ATK. All the objects are contained in the application.

Each object is initialised through “adding”, such as $api->add(‘Logger’); This will initialise class, bind it’s properties ($owner, $api, $template) and fire init() method after that. You can safely assume that each object have $owner and as you go up ($this->owner->owner->owner->owner), you will eventually hit the $this->api; This structure allows you to actually have multiple APIs deployed and both working without conflicts.

Another benefit is universal and unique name generation. Each object will have $this->name property looking like “MyApp_hello_HelloWorld”. ATK ensures that each name is unique and this name often is used for <div id=”">, in POST/GET, Sessions etc. For instance you may have a class GreetingsPage which will use $this->memorize() to save name of the user. If you will deploy 2 separate pages, they will each memorize name individually and will not clash.

About these ads