Routing is the process by which Agile Toolkit determines which code to run in response to a request.
Requests are passed to the webserver from the browser in the form of a URL. Each URL should define a unique resource for your app to return to the requester. It is considered a proper design if URL alone can fully determine user's desired action - avoid storing some routing logic in Session data or POST data. Here is a typical URL:
http://example.org/admin/user/edit?user_id=132
Routing in Agile Toolkit is a simple yet sophisticated method and can be easily adopted to handle URLs like this:
http://en.example.com/about.me
http://johndoe.mysites.com/
http://listings.com/houses/riverside-lake-3-bedroom/apointments/6545/edit
Agile Toolkit will parse your URL on request and connect it to the proper code. It will also generate URLs for you. Select sub-topic or continue reading for introduction.
- Interpretation and parsing of URLs
- Generating URLs and redirecting, relative URLs
- Sticky GET arguments
- URLs to your assets: images, css, js
- Using PatternRouter for SEF (search engine friendly) routing
- Application - dependent routing - ApiFrontend, ApiWeb, ApiInstall, ApiAdmin
Agile Toolkit is following Model View Presenter. Presenter contains presentation logic. To keep things simple we call it "Page". In other words, "Page" object is responsible of initializing all other elements you have on your page.
Routing is the process which determines which Page class should be loaded and used.
- PageManager is a standard class designed to break down your URL into essential components (explained below in more details)
- PatternRouter is an optional step which can convert "beautiful" or SEF URLS into normal form.
- Application routes page to a class or a method
- Page object continues to initialize objects.
All request to Agile Toolkit must be translated into four essential parts as displayed on the graph to the right.
If the URL is search-engine friendly and some arguments are hidden in the "page" part, they need to be extracted by PatternRouter. Note that you may use Controller_PatternRouter or you may write your own extraction logic, but this transformation must take place inside your Application::init().
You should also note how slashes are distributed. base_url has no training slash, while base_path always begins and ends with a slash.
It does not matter how exactly you route your request - as long as it reaches the Application class (which is typically through index.php), that should be acceptable. Below is a sample .htaccess file which you can use in your installations:
RewriteEngine On
RewriteRule ^[^\.]*$ index.php [L]
If you are running NGINX, here is sample configuration:
location ~ ^[^.]*$ {
include /etc/nginx/fastcgi_params; ##Includes our fastcgi setup
fastcgi_param SCRIPT_NAME "/index.php";
fastcgi_param SCRIPT_FILENAME "/www/path/admin/index.php";
}