Like every PHP frameworks, FrameBeurk is made of a set of scripts that are hosted on a distant server machine (*), on which a http program server (example : Apache) is operationnel and running a PHP interpreter module.
When the Internet browser of the user sends a request to the http server, this one runs the appropriate PHP scripts, which generate a page of HTML code (or CSS, Javascript, RSS…) that is sent back to the browser. The browser interprets this code to show a new page or to modify the page already on screen.
(*) : or possibly installed on the computer of the user or programmer, like in the case of the using of LAMP/WAMP (Linux-Apache-MySQL-PHP, Windows-Apache...)
Most actions of the user in his Internet browser trigger the sending of a http request to the server. Let's call « transaction » what happens between such an action and the taking into account of the response by the browser, and especially the process taking place on the server between the arrival of the request and the sending of the answer.
The exchange of data between the user Internet browser and the server works through a « pseudo-conversational » mode. This means that from the point of view of the user, there is no discontinuity between 2 transactions. On the contrary, on the server side, the execution of the scripts is interrupted at the sending of the response and the scripts are removed from the memory. The discontinuity is complete.
To keep the consistency of the dialog -i.e. the succession of transactions, the values of variables that have to be re-established at the start of the next transaction are stored in a session : PHP saves them outside of the http server (for a limited and parameterized duration, 30 minutes for example).
The dialogs of several users browsing the same site at the same time are completely separate.
Framebeurk is modular, parameterizable and expandable. The features and renderings specific to the site, shared by all users, are set up by parameters that form the configuration of the site. In order to improve the performance of the framework, the configuration is calculated at the start of the first transaction of the user, and then saved in a PHP session.
Regarding FrameBeurk as an applicative framework, the actions sent to the server -actions that are usually triggered by the user (for example when this one clicks on a link or a button), are of two kinds :
In FrameBeurk, a transaction will be made of at most 1 Maj action and 1 Vue action. If a Maj action is requested, it will always be processed first, because it can have effects on the data returned by the Vue action.
It is the user Internet browser that sends to the server the information about the Maj and/or the Vue actions to perform, in the parameters of the http request.
The request can also specify an error Vue to return instead of the normal Vue, in case of an error during the Maj action.
As I put forward at the beginning of this document, this framework proposes to developpers an approach of the business needs different from the Object-Oriented Analysis, and a sequential or procedural implementation simpler than OOP (see chapter 9). To stay clearly away from the object paradigm, the object-equivalents are called Entities.
Let's try this definition : An Entity is the projection of a business object on the applicative interface. It can be basic or complex, but unlike in OOP, it will never be declared in a core way. The entity will define the actions of Maj and/or Vue type that are available for users.
The Entities are gathered in functionnaly consistent sets that are named Modules.
Modules can naturally be dependent on each other. One simple example is the calling in a script of module B of a PHP function defined in module A.
If module A declares « function A_fonct() {…} » and module B implements a call to this function « $maVar = A_fonct() ; », module B is dependent on module A and will not be able to work without it.
The documentation of module B shall explicitly hightlight this static dependency.
The PHP language allows to store the name of a function in a variable. In FrameBeurk, we use this possibility to make a module call a function defined in another module, without being definitively tied to this module.
Example : The module B uses an alias (i.e. a variable) to call an external function implemented in module A. The website's configuration (*) associates the alias used in module B to the function declared in module A. This weaving between modules is called « Tissage ».
The documentation of module B shall explicitly hightlight the aliases to define for dynamics dependencies.
(*) : The weaving can be directly set up in module A if this one is statically dependent of module B.
Making an attempt to describe it simply, the HTML page shown by the browser is a set of boxes named « div », included or laid side by side, which contain the business information. The arrangement of divs within each others (and their rendering) is set-up by the style sheet (.css file) declared in the header section of the HTML page which is sent by the server to the browser.
The page layout is usually very steady from a page to another of the same website. Therefore it is very interesting to help the management and the processings associated with the layout. This framework proposes to handle it in the configuration of the website with the following items :
The template (named « Patron » in FrameBeurk) defines the main parts of the page where contents will be dynamically inserted by a controller (see this concept further below).
The content of each Div is defined in configuration. Typically, it is a label, a variable or a PHP file to include. When processing a part of the template, the controller includes into it the content of the Divs whose names begin like the processed part. For example : If the template has a div named 'Part1' in which the controller is called, and that the Divs named 'Part1a' and 'Part1b' are described in configuration, they will be declared in 'Part1' and their contents will be inserted there.
A Layout is the association of a template with declarations of Divs.
In order to assure the best performance to the website, the exchanges with the server are reduced to the minimum in terms of numbers and volumes :
For this last feature, specific Javascript functions of the framework implements the Ajax technique (Asynchronous Javascript and XML) following an unobstrusive mode (i.e. links keep on working without Javascript, reload the full page).
(*) : The reloading of CSS and JS files by the browser will be forced by the changing of the version number of the website on the server.
(This feature is still in planning stage. Nothing has yet been developed.)
When a vue is reloaded alone without the whole page, it may happen that the content of un-refreshed vues is no more up-to-date (for example if a Maj action has been processed). To ask the refreshing of these Vues after the server answer, an event management is established between the server and the Internet browser of the user.
