CMS architecture
Having more than enough time, I was carried away by reflections on creating a flexible, multi-functional, but relatively simple CMS for programmers and its user configurators. Some ideas were inspired by the potential of CMS Drupal. And now, fascinated by the realization of ideas and having successful intermediate results, I decided to tell about the architecture of the CMS created. In the course of reading the overall picture of the capabilities of the CMS should be drawn by itself, at least for programmers :)
The architecture of the created system is based on a modular principle. CMS is completely built from modules, like a children's house of cubes. In order to achieve flexibility and ease of interaction between the modules, it was necessary to achieve minimal actions for the use of modules by any component of the system without the need to create rigid connections, as well as to make it possible to easily extend the actions of the modules using other modules.
Figure 1. CMS - a set of modules
A module in terms of the system being created is a static class whose name is determined by the name of the module. For the functioning of many modules, a single static class is not enough - additional software structures can be used, which are implemented in separate files. All module files are located in one directory (folder), and module directories in modules.
')
In the root of the web directory there is an index.php file and a basic configuration file config.php. When any request to the site, the server executes the index.php file, it is from it that the system begins to function.
The system module of the System and the configuration file config.php are connected to index.php. After loading the configuration file, control is transferred to the system module.
Figure 2. Running the system module - cms kernel
The system module provides automatic connection of all other modules and is the core of the system, bringing it into execution. Automatic connection of modules is provided by the php-function __autoload ($ class_name). This function is defined in the system module file, but outside its class. When accessing an unloaded class, the PHP interpreter accesses this function; the function, in turn, accesses the system module. The system module determines the presence of the requested class (module), the location of its php-files and connects them.
After connecting the class files, the system module automatically calls the static Activate () method of the connected class (if it exists), which allows static classes to be initialized. Modules, as you remember, are static classes and many need initialization before working.
Thus, to use modules, you do not need to pre-declare or connect anything, it is enough to simply refer to the methods or properties of the module class, and you do not need to create references (pointers) to the modules. This is the principle of simple use of modules by any component of the system.
The Events event module provides the ability for modules to generate events. Events are generated by calling the
The System module of the system does not determine the further functioning of the system, it simply generates three events in turn: “initialization” (INIT), “execution” (START) and “completion” (STOP).
Any module can handle these events and thus participate in the functioning of the system. But not only the system module generates events. The figure shows the main system events (circles) and their connections (lines in a strip) with the modules that process events.
Fig. 3 Highlights
The modules that generate events do not know who handles their events. Any module can register to handle any event. Registration for an event is sufficient to do once during the installation (installation) of the module. The integrity of information about which module has registered for which event is provided by the Event event module. Below is an example of registering and deleting it on the “initialization” event (INIT) of the System system module by the Errors error module.
Application of events allows you to expand the actions of the modules that generate events, or simply respond to the actions of these modules.
By the way, remember how modules are loaded - only the first time you access them. This means that before the START event is generated by the system module, only the System system module and Events event modules, Errors errors and Session sessions will be loaded. The Errors and Session modules are loaded because they processed the INIT event, and the Events module is loaded, because the system module used it.
The “initialization” event (INIT) of the system module will first of all process the error module Errors, while it will also automatically load. The error module overrides standard PHP error and exception handlers. There is no need to talk about it in detail. It can be mentioned only that the error module in turn generates events after error handling, which allows, regardless of the cause of the error, to form a clear answer to the user by the modules generating the output, for example, by the Page module.
There is nothing special in the work of the Session sessions module, the module is launched at the system module initialization event, it identifies the user session identifier and then provides access to the session data as the Request request module.
The event “execution” (START) of the system module is processed by the Request module. The request module collects all incoming data from the user into a “container”, from which they will be available to any module of the system. To get data from the "container", you need to specify the format - the type and the size limit of the expected value. Thus, to some extent the penetration of data that does not meet the requirements of the modules is prevented. After completion of the process of placing the incoming data in the "container", the query module generates an AFTER event about the completion of its main work.
On the user's request, as a rule, it is necessary to form a conclusion - the answer, and send it to the client. The answer is usually the html page, but it can be a document in a different format, such as XML, or a file, or something else. Depending on the parameters of the user's request (url'a), one module is defined to form the output, more precisely, each output module itself determines whether it works or not in such a way that in the end only one module is responsible for generating the output. Output modules begin their work by processing the AFTER event of the Request module, which makes it easy to add new modules to form output in other formats. In principle, any module can be an output module, if it is at least something to pass to the user.
Before forming the output, it is necessary to process the incoming data. They can be form data that should be saved in the system. This is done by the Data Data module, handling the AFTER event of the Request module.
In the figure, the arrows show the data flow: the user makes a request to the server (transmits data), the received data is processed by the system modules, each module performs its actions with the data, and the result is formed, which is transmitted to the user. The data is transmitted by direct access to the methods or properties of the module. The module that receives the data first requests it. For example, the Data data module, processing the event of the Request module, starts its work and first of all refers to it (to the Request module) for data.
Fig. 4 Data Flow
Data module Data - the most important module of the system, it depends on its capabilities flexibility and functional power of the system. The data module provides data sharing. Allows them to create, modify, delete, and search with powerful features. Only the data module accesses the database through the Database module. To work with data, other modules do not use SQL queries, they use a simple but flexible way of describing query conditions, as well as methods for manipulating data. A data module based on conditions creates a SQL query to the database and returns data objects. Having received the “News” object, you can, without explicitly referring to the data module, find out everything related to the news — even the author of the section to which the news belongs. Thanks to the data module, the user-configurator (and the system itself) can create its own data classes — its own data structures. This and many other things will be discussed in the next article. For clarity, I will only add that the data class does not have a direct connection with the class structure of a programming language.
The data module also generates events, by processing which you can perform additional actions with data objects when they are saved, read and deleted.
The module of Page pages, using design templates, forms the html page, which is then sent to the user. The page is formed from blocks in accordance with the input data - request parameters (url'a). The page module makes extensive use of the data module, since a page is a representation of data, and many fragments — blocks of pages — are also data. The principle of page generation and all the subtleties of the functioning of the module is the topic of one of the following articles.
File and photo modules are one of those modules that complement the actions of the data module. In addition, the modules of files and photos, when installed in the system, create data classes “File” and “Photo”, respectively. After that, when the Data data module works with the objects of these classes, the file or photo modules perform additional actions. In particular, when creating a data object "File", the file is downloaded to the server and stored in the server file system. The file module is also the output module. With appropriate requests, the module transfers files to the user for download, while access control, statistics and everything the system as a whole can do.
The main function of the photo module is photo scaling. Since the photo is a file, it must also be able to upload it to the server, for this the file module is used.
The Actions module Actions allows you to classify and control the actions performed by the Data module on objects. Theoretically, any logical expression can be a condition for performing an action: it can be a check of the current user (its properties), a check of the object on which the action is performed, and more.
Example: The Data module of Data loads data from the database and generates a read event that is processed by the Actions module of actions. The Actions module Actions checks the conditions of this action and calculates the possibility of its execution, the logical result of the calculations is accepted by the Data data module, which simply obeys the result, that is, it continues or finishes reading the data object. The condition and the action are also data objects. Understand the intricacies of the module Actions Actions and flexible control actions can be after studying the data module Data.
The task of the Formats formats module is to provide various formats for values. For example, for strings, the formats will be representations of e-mail addresses, telephones, formats of formatting (markup). A format is a data object that is associated with a value object, which determines the format for the value. The format module does not just provide format objects, it also provides for checking values ​​for compliance with the format. The check itself occurs when the Data module of the data saves the data object. Also, some value conversions (text formatting, for example) according to the format occur when reading data. With the operation of this module, there are still many unresolved issues. Work continues.
I talked about two ways of interaction between modules - using direct access to methods and through event handling. Other topics covered concerning the functions and purpose of the main modules are considered superficially, only to show a general picture of the functioning of the system.
Project site http://boolive.ru
Continued: Data Model
CMS architecture
The architecture of the created system is based on a modular principle. CMS is completely built from modules, like a children's house of cubes. In order to achieve flexibility and ease of interaction between the modules, it was necessary to achieve minimal actions for the use of modules by any component of the system without the need to create rigid connections, as well as to make it possible to easily extend the actions of the modules using other modules.
Figure 1. CMS - a set of modules
Module
A module in terms of the system being created is a static class whose name is determined by the name of the module. For the functioning of many modules, a single static class is not enough - additional software structures can be used, which are implemented in separate files. All module files are located in one directory (folder), and module directories in modules.
')
In the root of the web directory there is an index.php file and a basic configuration file config.php. When any request to the site, the server executes the index.php file, it is from it that the system begins to function.
System System Module
The system module of the System and the configuration file config.php are connected to index.php. After loading the configuration file, control is transferred to the system module.
Figure 2. Running the system module - cms kernel
/** * index.php * . */ // // require('modules/system/System.php'); // require('config.php'); // System::Process(); The system module provides automatic connection of all other modules and is the core of the system, bringing it into execution. Automatic connection of modules is provided by the php-function __autoload ($ class_name). This function is defined in the system module file, but outside its class. When accessing an unloaded class, the PHP interpreter accesses this function; the function, in turn, accesses the system module. The system module determines the presence of the requested class (module), the location of its php-files and connects them.
/** * (). * PHP * @param string $class_name (). */ function __autoload($class_name){ System::IncludeClass($class_name); } After connecting the class files, the system module automatically calls the static Activate () method of the connected class (if it exists), which allows static classes to be initialized. Modules, as you remember, are static classes and many need initialization before working.
Thus, to use modules, you do not need to pre-declare or connect anything, it is enough to simply refer to the methods or properties of the module class, and you do not need to create references (pointers) to the modules. This is the principle of simple use of modules by any component of the system.
Events module
The Events event module provides the ability for modules to generate events. Events are generated by calling the
Events::Send($module_name, $event_name) method Events::Send($module_name, $event_name) . Events are handled by static methods of classes of other modules, although nothing prevents the module from processing its own events.The System module of the system does not determine the further functioning of the system, it simply generates three events in turn: “initialization” (INIT), “execution” (START) and “completion” (STOP).
static function Process(){ // : // Events::Send('System', 'INIT'); // Events::Send('System', 'START'); // Events::Send('System', 'STOP'); } Any module can handle these events and thus participate in the functioning of the system. But not only the system module generates events. The figure shows the main system events (circles) and their connections (lines in a strip) with the modules that process events.
Fig. 3 Highlights
The modules that generate events do not know who handles their events. Any module can register to handle any event. Registration for an event is sufficient to do once during the installation (installation) of the module. The integrity of information about which module has registered for which event is provided by the Event event module. Below is an example of registering and deleting it on the “initialization” event (INIT) of the System system module by the Errors error module.
/** * */ static function Install(){ // // : // -, , -, - Events::AddHandler('System', 'INIT', 'Errors', 'Process'); } /** * */ static function UnInstall(){ // Events::RemoveHandler('System', 'INIT', 'Errors', 'Process'); } Application of events allows you to expand the actions of the modules that generate events, or simply respond to the actions of these modules.
By the way, remember how modules are loaded - only the first time you access them. This means that before the START event is generated by the system module, only the System system module and Events event modules, Errors errors and Session sessions will be loaded. The Errors and Session modules are loaded because they processed the INIT event, and the Events module is loaded, because the system module used it.
Error module Errors
The “initialization” event (INIT) of the system module will first of all process the error module Errors, while it will also automatically load. The error module overrides standard PHP error and exception handlers. There is no need to talk about it in detail. It can be mentioned only that the error module in turn generates events after error handling, which allows, regardless of the cause of the error, to form a clear answer to the user by the modules generating the output, for example, by the Page module.
Session Session Module
There is nothing special in the work of the Session sessions module, the module is launched at the system module initialization event, it identifies the user session identifier and then provides access to the session data as the Request request module.
Request Request Module
The event “execution” (START) of the system module is processed by the Request module. The request module collects all incoming data from the user into a “container”, from which they will be available to any module of the system. To get data from the "container", you need to specify the format - the type and the size limit of the expected value. Thus, to some extent the penetration of data that does not meet the requirements of the modules is prevented. After completion of the process of placing the incoming data in the "container", the query module generates an AFTER event about the completion of its main work.
On the user's request, as a rule, it is necessary to form a conclusion - the answer, and send it to the client. The answer is usually the html page, but it can be a document in a different format, such as XML, or a file, or something else. Depending on the parameters of the user's request (url'a), one module is defined to form the output, more precisely, each output module itself determines whether it works or not in such a way that in the end only one module is responsible for generating the output. Output modules begin their work by processing the AFTER event of the Request module, which makes it easy to add new modules to form output in other formats. In principle, any module can be an output module, if it is at least something to pass to the user.
Before forming the output, it is necessary to process the incoming data. They can be form data that should be saved in the system. This is done by the Data Data module, handling the AFTER event of the Request module.
In the figure, the arrows show the data flow: the user makes a request to the server (transmits data), the received data is processed by the system modules, each module performs its actions with the data, and the result is formed, which is transmitted to the user. The data is transmitted by direct access to the methods or properties of the module. The module that receives the data first requests it. For example, the Data data module, processing the event of the Request module, starts its work and first of all refers to it (to the Request module) for data.
Fig. 4 Data Flow
Data Module
Data module Data - the most important module of the system, it depends on its capabilities flexibility and functional power of the system. The data module provides data sharing. Allows them to create, modify, delete, and search with powerful features. Only the data module accesses the database through the Database module. To work with data, other modules do not use SQL queries, they use a simple but flexible way of describing query conditions, as well as methods for manipulating data. A data module based on conditions creates a SQL query to the database and returns data objects. Having received the “News” object, you can, without explicitly referring to the data module, find out everything related to the news — even the author of the section to which the news belongs. Thanks to the data module, the user-configurator (and the system itself) can create its own data classes — its own data structures. This and many other things will be discussed in the next article. For clarity, I will only add that the data class does not have a direct connection with the class structure of a programming language.
The data module also generates events, by processing which you can perform additional actions with data objects when they are saved, read and deleted.
Page Pages Module
The module of Page pages, using design templates, forms the html page, which is then sent to the user. The page is formed from blocks in accordance with the input data - request parameters (url'a). The page module makes extensive use of the data module, since a page is a representation of data, and many fragments — blocks of pages — are also data. The principle of page generation and all the subtleties of the functioning of the module is the topic of one of the following articles.
Files and Photo Files Module Image
File and photo modules are one of those modules that complement the actions of the data module. In addition, the modules of files and photos, when installed in the system, create data classes “File” and “Photo”, respectively. After that, when the Data data module works with the objects of these classes, the file or photo modules perform additional actions. In particular, when creating a data object "File", the file is downloaded to the server and stored in the server file system. The file module is also the output module. With appropriate requests, the module transfers files to the user for download, while access control, statistics and everything the system as a whole can do.
The main function of the photo module is photo scaling. Since the photo is a file, it must also be able to upload it to the server, for this the file module is used.
Actions Module Actions
The Actions module Actions allows you to classify and control the actions performed by the Data module on objects. Theoretically, any logical expression can be a condition for performing an action: it can be a check of the current user (its properties), a check of the object on which the action is performed, and more.
Example: The Data module of Data loads data from the database and generates a read event that is processed by the Actions module of actions. The Actions module Actions checks the conditions of this action and calculates the possibility of its execution, the logical result of the calculations is accepted by the Data data module, which simply obeys the result, that is, it continues or finishes reading the data object. The condition and the action are also data objects. Understand the intricacies of the module Actions Actions and flexible control actions can be after studying the data module Data.
Formats Format Module
The task of the Formats formats module is to provide various formats for values. For example, for strings, the formats will be representations of e-mail addresses, telephones, formats of formatting (markup). A format is a data object that is associated with a value object, which determines the format for the value. The format module does not just provide format objects, it also provides for checking values ​​for compliance with the format. The check itself occurs when the Data module of the data saves the data object. Also, some value conversions (text formatting, for example) according to the format occur when reading data. With the operation of this module, there are still many unresolved issues. Work continues.
Conclusion
I talked about two ways of interaction between modules - using direct access to methods and through event handling. Other topics covered concerning the functions and purpose of the main modules are considered superficially, only to show a general picture of the functioning of the system.
Project site http://boolive.ru
Continued: Data Model
Source: https://habr.com/ru/post/51152/
All Articles