« HackBBS Reloaded » : différence entre les versions
Aucun résumé des modifications |
Aucun résumé des modifications |
||
Ligne 35 : | Ligne 35 : | ||
D'une manière plus générale, retenez seulement que vos modules ne devraient accéder QUE a la couche business du noyau. | D'une manière plus générale, retenez seulement que vos modules ne devraient accéder QUE a la couche business du noyau. | ||
=== Couche provider (Interface utilisateur) === | |||
Une interface de type "terminal" a été retenu. Ce type d'interface pose en temps normal des problèmes d'expérience utilisateur, mais s'agissant d'un site de chall, ceci n'entre pas vraiment en ligne de compte. | |||
La gestion du terminal est effectué par des fonctions javascript utilisant la lirairie JQuery et ses extensions jTerminal et JQueryUI. | |||
La communication entre le client et le serveur se fait en JSON. C'est en fait un objet DataBusVO sérialisé qui est échangé entre le client et le serveur. La sérialisation est gérée par le script dispatcher.php | |||
L'ensemble du travail des modules consiste donc à générer une instance de DataBusVO qui sera récupérée par dispatcher.php pour modifier l'affichage côté client. |
Version du 17 septembre 2013 à 18:53
Introduction
Avec l'age, de nombreuses fonctionnalitées ont été rajoutées à HackBBS. La qualité originelle du code et les modifications successives ne permettent plus d'avoir quelque chose de maintenable. C'est dans cette optiue que la refonte du site a été envisagée.
Contraintes
- Utiliser l'installation et la configuration actuelle du serveur Apache2
- Utiliser des technologies les plus connues et les plus répandues possibles. (Ce qui permettra une implication plus large de la communautée)
- Utiliser des technologies permettant une modularité
- Utiliser des technologies pouvant s'interfacer avec MySQL (Réutilisation de la base de données existante)
- Limiter au maximum l'utilisation de frameworks pour que le projet soit maintenable avec un bagage de connaissances minimum
Technologies retenues
- PHP
- PDO
- Ajax
Architecture
Il s'agit d'une architecture 3 couches:
- Une couche gère l'interface utiisateur
- Une couche contient le code métier
- Une couche consomme les différents services (Tape dans les bases de données, envoie les emails, etc.).
Le diagramme ci dessous vous présente l'architecture retenue. Une ligne pleine représente une notion de dépendance, une ligne pointillée un flux de communication.
hxxp://imagik.fr/view-rl/48310
La communication entre les couches DOIT suivre le sens indiqué par les flèches. Par exemple, appeller des fonctions dans la couche Consumer depuis la couche Business est autorisé. Par contre appeller des fonctions de la couche Business depuis la couche Consumer est interdit.
D'une manière plus générale, retenez seulement que vos modules ne devraient accéder QUE a la couche business du noyau.
Couche provider (Interface utilisateur)
Une interface de type "terminal" a été retenu. Ce type d'interface pose en temps normal des problèmes d'expérience utilisateur, mais s'agissant d'un site de chall, ceci n'entre pas vraiment en ligne de compte. La gestion du terminal est effectué par des fonctions javascript utilisant la lirairie JQuery et ses extensions jTerminal et JQueryUI.
La communication entre le client et le serveur se fait en JSON. C'est en fait un objet DataBusVO sérialisé qui est échangé entre le client et le serveur. La sérialisation est gérée par le script dispatcher.php
L'ensemble du travail des modules consiste donc à générer une instance de DataBusVO qui sera récupérée par dispatcher.php pour modifier l'affichage côté client.