The X-ray of Beurky PHP's head shows the main lines of the fonctional structure of FrameBeurk.
The first process to be executed -whatever is the entry point, is the calling of the bootstrap. This one runs all preliminary operations for a flawless transaction :
The communication layer with the database must define all the read/update functions used in modules. As of today, the 2 layers included in the framework are front-ends to mysql and mysqli interfaces.
Here, the concept of controller is a little bit different from the one of MVC model. In FrameBeurk, whatever part of a script handling a list, especially to check that an input variable has its value in the list, can claim to be a controller. The main controllers are :
It receives the standard parameters of a Maj action and checks their compatibility with the configuration
loaded by the bootstrap.
In particular : The type of entity should exist, the Maj code must exist for this entity, the user profile should be authorized to process this action...
When all controls are OK, the PHP code of the action is executed.
The principle is the same than the previous one. It receives and checks values of the key variables of the requested Vue :
The type of entity should exist, the Vue code must exist for this entity, the user profile should be authorized to proceed to this action...
When all controls are OK, the PHP code of the action is executed.
This controller is included in the template once for each div in which dynamic content has to be inserted.
It loops on the list of divs parametered in the configuration file and
insert those whose name matches, with their content that can be (1 or more among) : static string, PHP variable, content generated by a
Vue or widget.
The entry point of the framework varies depending on the type of the data to be returned (html, rss, css, js) and, for the HTML code, if the full page has to be displayed or only a Vue (with Ajax).
Below, the flowcharts of the different entry points.
Flowcharts are both the same, except for the template used for the output of the HTML code.
Therefore they share the same diagram :
In case of URI rewriting, the http server has to be set-up to substitute
« index.php » or « ajax.php » for « interpreteur.php ». In this case, it is the interpreter
that loads the bootstrap.
The purpose of the interpreter is to analyse the rewrited URI to feed the PHP parameters
that are usually processed by index.php and ajax.php
FrameBeurk can handle several style sheets for the same website, that can be chosen by the user or by the configuration.
This script sends in a single file all the css declarations linked to the modules and patron, depending on the selected style.
All the same, this script sends in one file all javascript declarations of the used modules and patron.
This entry point is meant for RSS feed. It does not call Maj controller.
The PHP code of a Maj action will usually contain the following sections :
The Vue actions are often more complex than Maj and will be helpfully split in independants parts, tearing apart SQL data-base requests from PHP scripts generating the HTML code.
Vues will be made of series of calling to PHP functions returning the following items :
A query is a PHP function returning a SQL request for reading the data-base, request that can be either a string or an array (see further paragraph « DB Communication layer »).
Queries refering to an entity are gathered in a model file stored in the folder of the entity.
A Card is a PHP function whose purpose is to generate a block of HTML code from the resultSet returned by the execution of a Query. Usually, a card formattes the data of an entity and displays buttons for the Maj actions which are available depending on the status of the entity and the user profile.
Cards refering to an entity are gathered in a helper file stored in the folder of the entity, or upper in the folder of a module if the PHP script may be shared by severeal entities.
