Intro » Data Model Binding

The next important pattern used in Agile Toolkit is binding View with Model.

In MVC concept the lead role is taken by Presenter (or Page class in ATK). When your application user directs his browser towards your web app, application determines which page to show, then initializes it and renders.

The page can often receive additional GET arguments, such as:

http://example.com/myapp/message/view.php?id=123

The purpose of the page is to:

  • determine which UI object will be used
  • determine which Model object will be used
  • pass ID to the Model object
  • pass Model object to UI

Looking at the code, you will see something like this:

class page_message_view extends Page
{
    function init() {
        parent::init();

        $v = $this->add('View_MessagePreview');
        $v->setModel('Message')->load($_GET['id']);
    }
}

At this junction you must understand about different roles that those classes play:

  • Model_Message - responsible for business logic of the "Message", such as retrieving it from database, performing business actions like "reply()", "markAsUnread()". Must NOT contain any UI-related logic and must NOT assume in which circumstances it will be used.

  • View_MessagePreview - a widget that is responsible for presenting message to the user through HTML. It can also bind certain actions by using a "Button" class such as "Mark as Unread". The View MUST NOT contain any business-logic such as working directly with the data-base but it can rely on public methods of Model_Message. View also MUST NOT assume in which contexts it will be used, which page or what GET argument it will receive.

  • page_message_view - a page that is responsible for binding View with a Model. The page MUST NOT contain any business logic or any presentation logic.

Application Class Scope

In Agile Toolkit you will always have "Application" object in memory. Depending on the type of application it would have various URL->page routing mechanics. All the other objects are created as "children" of Application and will therefore carry reference to the application class.

This is useful for various things, for example 'Model_Message' will be able to locate your database connection and load data from it without you having to specify it manually.

There are different Application Prototype classes if you are building API or CLI interface you would use a different application class. If your model has a need to interact with other controller of the application, this can be done through the Application:

function sendThisMessage() {
    $body = $this->getMessageBody();
    $recipient = $this->getRecipientAddress();

    $sender = $this->app->auth->model->get['email'];

    $this->app->outbox->send($sender, $recipient, $body);
}

When you're writing Unit tests for your business logic you will be able to mock "outbox" and properly test the methods.

Continue to next page..