root
, path
and base
entry points.
basic
, index
and standard
logics. Each of these logics depending on the preferred logic, defines the main or root controller file that will be responsible for managing routes.
The root controller file can be a single top level controller file or multiple top level controller files that are used to manage their relative subroutes.
index.php
file at the root of the project application
must be configured to use the super controller name. This is done by supplying the super controller name in the Server::run()
method. An example is shown below:
<?php
include 'icore/filebase.php';
↪ Server::run('basic');
windows/Routes/Basic.php
file controls the entire application. The namespace is generated from the supplied
super controller's file name (i.e basic). If the file (i.e class) exists within the predefined path, then the class will take the full ownership and control of how urls run. This means that
every url will first land on that windows/Routes/Basic.php
file which will then determine how such url is handled. In this manner,
the Basic file is the sole distributor and manager of all urls. Without it, pages will not be able to load.
windows\Routes\Index
namespaced class takes the full ownership and control of how urls are handled. When an index page
(e.g http://host_name/
or http://host_name/index
) is visited, the namespaced index class will resolve
the index page by calling its root()
method. However when other urls whose entry names are not index are called,
then spoova will try to resolve the urls by looking for a file with the root name within the windows/Routes
directory.
If the file does not exist, then spoova will return a 404 error page. The structure below is an example of how to set up an index logic.
<?php
include 'icore/filebase.php';
↪ Server::run('index');
<?php namespace spoova\mi\windows\Routes; use Window; class Index extends Window { function __construct(){ if(self::isIndex($this)){ self::call($this, [ window('root') => 'index', //call index method for only index pages ]); } else { //call other pages using the currently visited url's root name as the route controller class name //if route controller class name does not exist, close and return 404 response. if(!self::callRoute(window('root'))) self::close(); } function index() { //this method is only called for index page } } }
In the code above, by setting the index.php
file to
Server::run('index')
, the application will try to call the windows\Routes\Index.php
.
If the file exists and the currently requested url is an index page, the windows\Routes\Index.php
file will in turn call its index()
method
using the shutter method call()
.
However, if a different url is called whose entry point name is not "index"
, rather than call the index()
method,
the management structure will check if the route file exists first within the windows\Routes
directory and try to use the class to
resolve the url. The self::callRoute()
method ensures that
the window tries to load every page using a class entry window name that exists within the windows\Routes
directory. If the url handler or window router file
does not exist, then a 404 reponse is returned through the self::close()
method. To further explain this, let's take a look at two sample urls below:
http://localhost/app/home window('root') => home http://somesite.com/home window('root') => home
"home"
. The self::callRoute()
will try to see if the Home
route
class exists in the windows/Routes
directly and automatically load it. If the file does not exist, it will return a false value which will trigger the self::close()
method that returns a 404 error page. Assuming we have a localhost url
http://localhost/app/home
, then the window('root')
of that url will be "home"
.
In any given url, the root entry name returned by window('root')
or window(':')
is always the name that comes after the domain url. In localhost, it is the path name that comes after the project folder name. In the first url sample
above, the project folder name is app
, hence the window root is "home"
. However, in the second url since somesite.com
will most likely be the domain url, then the first path that follows becomes the window root. If there is no path found after these urls, this will be assumed as the index page.
http://localhost/app/home
and http://localhost/app/home/user/...
for example, will be handled
by a route file "Home"
where http://localhost/app
is assumed to be the parent domain part of the localhost url. This Home
file must be an extension of Window
class within the windows/Routes
directory and it will determine how its relative sub-paths are resolved. If the required route file does not exist, then a 404 error page is returned.
Futher explanation is given on window entry point here. In order to define a standard logic,
the Server::run()
code in root config file index.php
must have no arguments.
Server::run(); // use standard logic
<?php namespace spoova\mi\windows\Routes; use Window; class Index extends Window { function __construct(){ self::call($this, [ window(':') => 'root', window(':user') => 'user_method', ]); } function root() { //call this on index page } function user_method() { //call this on index/user page } }
window(':')
will return a requested
(or current) url's entry point name. Since, Index is the entry server file, then,
index
will be returned. Also, window(':user')
will return
index/user
. Since call()
is a direct shutter method,
if the method user_method()
does not exist when the http://domain/index/user
,
page is visited, then a 404 error will be returned. Once a method is defined, developer is left
to handle how to close such urls. Any of a window's method can use the shutter methods.
404
error page is returned. The route validations are
done through url entry points divisions. This divisions makes it easier to manage urls better based on desired requirements.
The sample below best explains how urls are subdivided or categorized for proper validation.
Type | Url sample | root | path | base |
---|---|---|---|---|
local | http://localhost/myapp/users/some/path | users | some/path | users/some/path |
remote | http://site.com/users/some/path | users | some/path | users/some/path |
"myapp"
. However, when it comes to remote live domain urls, the url divisions starts immediately
after the domain name site.com
because it is assumed that site.com
is equivalent to localhost/myapp
.
For this reason, both localhost/myapp
and site.com
will be given an alias of {domain}
. Using this alias, we can generalize the urls above in a new way below:
Url sample | root | path | base |
---|---|---|---|
http://{domain}/users/some/path | users | some/path | users/some/path |
root
part of any url is the first name that follows the {domain}
path of any url.
From the sample above, this is equivalent to
"users"
. Hence, the "users"
is the root division of the sample url. This division is the
main entry point to any url and it is sometimes referred to be the Window or entry point of any url. This is because this root part is the main controller of how
urls are resolved. In standard logic, the url root entry point is used mainly for top level controller files.
path
section (or part) of any url is the entire path that follows the root
section of any url.
From the sample above, this is equivalent to "some/path"
.
{domain}
section. In simple terms, this is the conjuction of the root
and the
path
divisions of any url. From the sample above, the base
division is equivalent to "users/some/path"
.
Url sample | root | path | base |
---|---|---|---|
http://localhost/myapp/ | index | {empty} | index |
http://localhost/myapp/index | index | {empty} | index |
http://localhost/myapp/users | users | {empty} | users |
http://localhost/myapp/users/some/path | users | some/path | users/some/path |
http://www.site.com/ | index | {empty} | index |
http://www.site.com/index | index | {empty} | index |
http://www.site.com/users/some/path | users | some/path | users/some/path |
root
part supplied, as in the case of the first and
fifth url samples, the root
name is automatically termed as "index"
rootcall()
,
pathcall()
,
basecall()
and
call()
methods. rootcall()
method validates the root section of a url only. No validation is done for relative subpaths.
pathcall()
method validates the path section of a url only. No validation is done for the root entry point.
basecall()
methods validates the specified base section of a url and does not validate subpaths.
call()
method validates the entire base section of a url allowing no subpaths.