FrameBeurk documentation
10. Miscellaneous
10.1. .htaccess File
Example of .htaccess file with URI rewriting, to put at the root folder of the website :
SetEnv PHP_VER 5
SetEnv REGISTER_GLOBALS 0
SetEnv MAGIC_QUOTES 0
<IfModule mod_rewrite.c>
RewriteEngine on
RewriteBase /Fmbk/
# exclusions
RewriteRule ressources/(.*) - [L]
RewriteRule ^index.php(.*) - [L]
RewriteRule ^ajax.php(.*) - [L]
RewriteRule ^js.php(.*) - [L]
RewriteRule ^css.php(.*) - [L]
RewriteRule ^rss.php(.*) - [L]
# redirection
RewriteRule (.*) interpreteur.php
</IfModule>
10.2. Personal Pages at free.fr
FrameBeurk has been conceived so it can be used on the free.fr personal pages, with a few limitations :
- PHP environment variables cannot be set in the .htaccess file.
- To take advantage of PHP version 5, the .htaccess file must contain the instruction « php 1 ».
- The rewriteEngine module of Apache is not available. URI rewriting will not work (*) and should be disabled in file config.php.
- The mysqli interface is not available. The DB communication layer included in the bootstrap should be « mysql_layer.php ».
The .htaccess file below is recommended :
php 1
ErrorDocument 404 /forum2/interpreteur.php
(*) : The instruction ErrorDocument redirects unresolved URI to the interpreter. One could consider
to use this way to make URI rewriting. Unfortunately, parameters sent by the POST method are lost during the 404 redirection.
Therefore, most of Maj actions would not work.
10.3. The concept of URI
The « address » sent to the framework with the GET method does not comply to the definition of an URL (Uniform Ressource Locator) neither an
URI (Uniform Ressource Identifier), because it can contain the parameters for a Maj action, an alternative (Vue or Error Vue) and lead to different displays.
We would need a more general term to qualify the « addresses » used in FrameBeurk.
Remark that block (2) of the diagram about URI rewriting (chapter « Features ») fits the concept of URI. It is this block (2) that is returned
by the server as the canonical URI of the page.
10.4. Implementation rules
This framework is built in procedural programming and as long as possible, in sequential programming - the code sequences being gathered by instructions include and require.
All the code share the same common namespace. Here are the implementation rules that have been chosen :
- Arrays $CONFIG, $DIALOG and $TRANSAC should be used to share information between components,
depending on the life time of variables.
- The parameters of the actions of the request are instantiated as global variables by the Maj and Vue controllers.
- Beside the 2 previous cases, the variables encountered in the code are local variables that are (should be ?) unset no further than the end of the PHP file.
- The names of PHP functions begins with the module name with the initial letter in upper-case, followed by an underscore. Example : Kom1_ajouteMaj(...)
- The names of Javascript functions begins with the module name with the initial letter in lower-case, followed by an underscore. Example : kom1_basculeAffichage(...).
10.5. Generation of HTML code
Having tested several styles of implementation for the output (echo) of the HTML code, it appears to me that :
- The PHP instructions embedded in the HTML code with <?php echo … ?> reduce the readability of the code as soon as their frequency increases.
- The PHP short tags < ? ou < ?= reduce the code portability.
- Using a template engine does not really improve the code syntaxe, but requires to learn another language, adds complexity in the PHP code ahead of the template,
adds a step of compilation of the template ...
- Indentation of the HTML code only « works » locally in the PHP file from where it is generated.
It is difficult to organise a correct indentation on the whole generated HTML file... It is also functionally useless.
So, I ended on a questionable writing that should nevertheless have the advantages of concision and of greater speed of execution by the PHP engine. Example (without context) :
echo
'<div id="', $nomDiv, '" class= "test">
', $ligne1, '<br />
', $ligne2, '<br />
</div>
';
- All strings are put between single quotes,
- Indentation is eliminated of HTML code, and locally disappears in the PHP code –the operande of instruction echo is left anchored.
- The line-feed escaped characters « \n » have disappeared in favour of real line-feed included in the constant strings.
- The principle could be worded like this : 1 line in the PHP code = 1 line in the HTML code.
Using the ternary operator is still possible with this writing, but the lisibility decreases :
echo
'<div id="', $nomDiv, '" class= "test">
',(($cas1 == true) ? ($ligne1 . '<br />
' . $ligne2 . '<br />')
: 'Pas dans le cas 1<br />'),
'</div>
';
This way of implementing is in no way mandatory to use FrameBeurk.
10.6. Prospective
Obviously this is only an alpha version and there is so much left to do. In the short or medium term :
- Fix all bugs !
- Eliminate all the dirty dependancies still present between modules.
For example, the user table of module Uzers contains a column to store the number of comments created in module Rhum (while module Uzers should not be dependant of module Rhum).
- Manage internationalization.
- Bring the event management to the client interface.
- Externalize the management of ratings and alerts into module Kom1, for mutualization. Ability to associate comments to entities other than Subjects.
- Bring to module Zeek a data model to store in database mp3, songs, albums, bands... and a management interface.
In the long term, as suggested by the X-ray of Beurky PHP's head illustrating this documentation, I want to give to this framework an architecture leading each website built with it
to be an Artificial Intelligence, that could behave like an agent.