FrameBeurk

FrameBeurk has been conceived with the former kinematic of the Pacbase workshop screens (3270 transactions in the IBM Mainframe world) in mind. Very roughly, a Pacbase screen is a program containing 2 parts :

• The first one does the updates (if there are some) in the database. This part is executed only if the user was already on the same screen.
• The second one sends the data to display on the terminal (the map), data which will possibly be modified at the next execution of the programme (in its first part).

Between these 2 parts, a switch can move the user to the display of another screen, according to the information he has input or to the pressing of a function key.

The port of this kynematic in the PHP framework FrameBeurk results in a unique entry point -the usual index.php file, that is successively executing :

• The update controller, that proceeds to the necessary checkings before executing the update action in the database.
• The view controller, which executs the action of reading the data to display and rendering them.
• The layout that integrates the output of the previous actions in the full html page or in an xml message (in the case of Ajax requests).

This scheme seems close to the sofware design pattern of Model-View-Controller (MVC), but i am not skilled enough in this matter to confirm it is fully respecting it.

FrameBeurk is implemented in PHP procedural and functional, without the usage of the object oriented features of this language, for an easier access to developpers and for other reasons that would be controversial here.

The organisation of the data in the memory makes a large usage (a little more at each version) of associative arrays.

A special attention has been given to the performance optimization :

• Reducing of the number of sql requests needed by each transaction,
• Improving of the speed of the bootstrap by storing the configuration of the website into session memory,
• Reducing of the number and the size of the data exchanged between the web client and the server, by an optimal Ajax browsing, by the merge of the css files (also javascript) of all the modules used on the website...

The text of the documentation of the v0.5 version is of an heterogeneous accessibility : Some points are written for people that does not know anything about a framework, some others will only make sense after looking at the files and scripts of FrameBeurk.

For a first step, chapters 1 and 2 deserve to be read before reaching chapter 8 -the installation of the framework.

In a second time, take back the study from chapter 3 until 9, which presents an analysis methodology for implementing applications with FrameBeurk.

This framework, as its documentation, is a work still in processs. Please feel free to share any constructive comment.

There you can look through the tree view of the FrameBeurk source files, in v0.65. This version is a little more advanced than the one of the documentation. In a few words, it brings :

• Language management : The Beurk_traduit function uses "Catalog" files, each of them containing an array that associates the labels in the tongue of the module implementation, to the labels in the target tongue.
  The labels to translate are extracted automatically by the TraducTeurk tool. After the developper has completed the translations of the labels in an Excel worksheet, TraducTeurk generates the catalog files.
Learn more about TraducTeurk
• The first version of the FrameBeurk Hypergraph : The Beurk_Lien table links together (almost) everything the framework handles.
  The Terminals declared in the Beurk_Terminal table make the link between the framework code (that uses their labels) and the hypergraph (that handles their numeric ids).