Application workflow

XirtCMS has inherited the application workflow from the CodeIgniter framework, but significant changes were made to fulfill the applications needs. The main changes made affect the router (which now connects directly to the database), the addition of widgets and the introduction of templates. In this article a high-level overview is given of the application workflow including an elaboration on the main components.

The following flow chart visualizes the process executed once a page of XirtCMS is requested by a client:

Visualization of XirtCMS processing of a request

Above flowcharts starts with the call of the application through index.php on the left side. From there, the following components might be called sequentially:

Based on the request properties used to access this file (which might be done using a SEF URL), the Router of CodeIgniter will determine which controller to use for the creation of the returned page. Different from the default CodeIgniter, this router has been enhanced to connect to the database to retrieve routing information rather than using configuration files only. Note that if a cached version of the page exists for the given request, the Router will trigger immediate sending of its contents as a response, bypassing most of the application flow.

The Security component of CodeIgniter filters any data within the request prior to usage by the controller. This prevents that user submitted data can cause security breaches while being processed within the controller. More information on the security features of CodeIgniter can be found here.

The Controller serves as an intermediary between Models, Views, and other resources needed to generate the main part of the returned web page. It has access to the database as well as shared helpers, libraries, models and or views that can be used for input parsing or the creation of output in various formats (e.g. XML, (X)HTML or JSON).

The finalized Views from the Controller then loaded into the Template configured for the application. This template can contain references to widgets and or XirtCMS specific views (e.g. header, footer) to enrich the final page.

From the template, optionally the system can include widgets to be processed and integrated into the template. Just like modules, widgets have database access and can rely on helpers, libraries, models and view for input / output processing. The result / output of widgets is immediately outputted to the template.

Helpers, Libraries, Models and Views support controllers and widgets by loading data, performing (routine) tasks and / or processing data into various output formats. By default, only Models are provided with database access, while helpers, libraries and views can only request database access through the parent instance using them. It is however not recommended to do this for views as such logic should be placed into a model instead to separate logic and output (MVC principle).

For pages that have infrequent changes, it is possible to significantly speed up their rendering and response time by using caching. The caching driver of CodeIgniter is used for this and basically saved prerendered versions of predefined modules that can be returned immediately without any action done by the controller. Note that caching will not affect widgets, hence pages can still look quite dynamic with caching enabled. More information on the caching features of CodeIgniter can be found here.

Responses (1)

sdf sdf
5 October 2019 02:22


XirtCMS - Copyright © 2018. All rights reserved. | GNU General Public License v3.0