Quick Start

Agile Toolkit is about results. It is about development of Web software. Specifically a dynamic, customizable and flexible Web Interface with a extensive and separated Business Logic. Agile Toolkit gives you, a developer, a faster ride.

It's impossible to copy concepts of other general PHP frameworks and make web development faster. That's why Agile Toolkit is different. It's easier to understand, easier to write. It takes care of things and all the components integrate seamlessly.

Developing with Agile Toolkit is the following of concepts of Agile Toolkit. If you are uncomfortable with those concepts, we suggest to use general-purpose framework. General purpose frameworks give choices, Agile Toolkit makes choices.

Choosing Api Class

The application you are about to develop using Agile Toolkit will require you to define at least one class. That class is called "Api" class and can be inherited from some of the standard Api classes. For a fully featured Web Application it's recommended that your API class is inherited from ApiFrontend. If you need to create a cron-script or command-line utility you should use ApiCLI component. ApiWeb class can be used if you are willing to integrate Agile Toolkit into other software / framework.

Api object is the "only" object which must be manually created. All the other objects are "added" either into Api or into other object. The resulting hierarhy is called "Runtime Tree".

Api class does not have require to have any functionality, however it would typically add a number of "Api Controllers" classes. Those would take care of page routing, database connection, authentication and other tasks.

ApiFrontend will initialize most of those controllers for you. It will also initialize page routing and will add a proper page.

Models

In Agile Toolkit Model reflects a business entity. "User" is a good example of a model. Models are implemented as classes, therefore you can inherit models from other models. For example "User_Administrator" could be inherited from "User", but would add additional fields and conditions.

Models are optional in Agile Toolkit, although we highly recommend you to learn and use them. All the standard views can work with static data, dynamic sql or models. Models contain field definitions, validation rules, relations and additional actions.

Helper

In Agile toolkit helpers are all sorts of other classes which are used but can't be classified in any other way. For example when you add field to model, FieldDefinition helper class will be used. jQuery_Chain is another helper class, which records actions for JavaScript binding. You can use 3rd party library classes and they would be considered "helpers" too.

Pages

Pages in Agile Toolkit are implemented as ... classes. Api class will automatically determine which page user tried to access and will "add" a proper page into itself. The page would be responsible for the content, which is specific to that page. In other words pages output will not affect header / footer of your HTML.

Each page has a name and pages can be nested. For example you can create a page "settings/password". On other hand you can create page "settings" and define "password" as a sub-page. Pages always inherit class "Page" either directly or indirectly.

If your page class cannot be located in page/ directory, the Api will add a generic page using "Page" class and will use static template located in templates/[skin]/page/

Views

View in Agile Toolkit is also a class. Anything what is producing an output is a View. Because Api and Page also produce output, they are descendants of AbstractView.

Any View object will have a template. Views can have a default template or it can be specified or inherited. For example — default template of Api class is "shared.html" — that's where your header/footer is. When you are adding view, you can instruct it to read template from a separate file or clone region from parent's template.

Another common property of all Views is called a "spot". That's a location in template of their parent where rendered output of a View is inserted. For instance, shared.html file contains a tag <?$Content?>. This tag is used as a "spot" for pages. Navigation menu is using spot <?Menu?>, which is also found in shared.html.

Controllers

Controllers are used as a glue in Agile Toolkit. They are also used to modify and enhance behavior of other objects. Controller is implemented as a class. Adding same controller twice into any object will result in only a single controller being added.

Understanding the Structure

In Agile Toolkit, everything is implemented as a class. Classes, however, play different roles such as Api, Page, View, Model, Controller and Helper. The only two non-object-oriented components are your templates (which are files with HTML fragments) and database (MySQL).

Structured Web Interface

First thing you will probably notice, is that while many other generic frameworks approach "page" as a entity to break into model / view / controller, Agile Toolkit implements a much different approach. Agile Toolkit looks at your page recursively. You might have "Accordion" in your page, inside which you may put a Form inside which you will add a button. Each of those 3 would have their own templates. Because templates in Agile Toolkit are universal, you can easily add anything anywhere and it will just work. This ability to break down your interface into component library then using them inside hierarchy is what makes Agile Toolkit an "UI" framework.

This clever implementation is delivered to a developer in a simplest possible way:

$accordion = $page->add('Accordion');

A regular developer of web software wouldn't need to worry about what happens behind the scenes. What is important is that you now have a working accordion on your page.

Continue to "Adding Objects"