Après une longue absence, un petit post pour présenter le projet IHM, les bases du projet Core étant bien avancées.
Et oui l'hiver arrive, et pas question de faire un IHM à l'arrache sous la neige ;)
Bon, plusieurs solutions :
- Un nouveau projet GUI avec communication sur CORE via Services WEB
- Un nouveau projet GUI avec dépendance CORE.
- Intégration dans le CORE.
Finalement, pour gagner du temps, j'opte pour la solution n°2.
Explications :
Solution 1 :
Optimale en terme de dépendance projet, il est tout à fait possible de faire une IHM avec le langage préféré (PHP, .NET, VB, C++, ...), il suffisait simplement de définir des WebServices de dialogue avec CORE équipés de leurs signatures XML lisibles par tout le monde. Une autre piste aurait été de réaliser un autre projet JAVA dédié GUI qui dialoguerait avec ce que l'on appelle des DTO (Data Transfer Object), le projet CORE <<exhibant>> les objets (sous forme d'un projet), ainsi la structure interne du Core peut changer mais pas ce qu'il expose (il assure le contrat de service).
Un peu lourd pour moi, je n'ai pas forcément le temps de tout développer aux petits oignons. A noter que de nombreux outils comme Dozer permettent le "peuplement" automatique d'un objet dans un autre, moyennant un peu de conf xml expliquant le mapping lien : http://dozer.sourceforge.net/
Solution 2 :
Evidemment, cette solution est plus rapide en terme de développement, on accède directement aux objets du projet CORE sans tout redéfinir. l'inconvénient est que si un objet évolue, on devra par capillarité se taper l'évolution côté GUI. Mais bon, le projet doit être cohérent.
Solution 3 :
L'intégration directe dans le CORE sans séparation de projet, me semble un peu trop incrustée à mon goût.
A noter, une version client (en ligne de commande est prévue), pratique lorsque l'IHM rebute un peu. car finalement on peut tout faire en ligne de commande.
Vous l'aurez compris, la solution 2 est engagée.
On commence donc par créer un projet JAVA WEB sous Eclipse :
On y retrouvera nos sources dans le packages src, les jsp, css, images et autres sous WebContent.
On déclarera les dépendances à l'aide d'un fichier pom.xml.
Alors pour la partie IHM, on utilisera un Pattern MVC (Model Vue Controller) qui permet de dissocier les écrans, du code, et du modèle. Ce pattern évite que l'on retrouve dans les beans (model) et les traitements (Controller) des morceaux de code liés aux IHM. Pour cela j'utiliserai Struts 2 http://struts.apache.org/2.x/
Contenu du WebContent :
Nos Jsp seront protégées sous WEB-INF.
Struts utilise un fichier de configuration xml qui détermine les actions (url) possibles sur votre site. Et l'action est redirigée vers une classe java qui retournera SUCCESS généralement, dans le fichier de configuration si success est renvoyé, Struts ira charger la JSP indiquée exemple :
Ici http://monsite/JdbAction sera redirigé vers JdbAction (Classe POJO), le result (SUCCESS par défaut afichera la jsp jjdb.jsp.
Contenu de src (ne pas tenir compte de beans, devices, ancienne version) :
On y retrouve comme prévu struts.xml à la racine. et sous ihm nous regrouperons nos classes actions (vu au dessus), les interceptors (qui permettent comme leurs noms l'indique d'intercepter n'importe quelle action) utilisation pour la sécurité, on y reviendra plus tard avec security. Servlets en cas de servlets à définir, et enfin tags si des tags sont à prévoir.
Voici donc à qui ressemble l'IHM (pour l'instant hyper sobre):
- Menu type dock Mac en haut
- Home.
- Alarme.
- Caméra.
- Luminaires.
- Fermetures.
- Températures
- ChatAction.
- Paramètres.
- Déconnexion.
- Corps de la fonction utilisée.
- Footer contenant les x dernières lignes du JDB (raffraichissement automatique avec AJAX)
Voila le squelette, reste à remplir maintenant, je commencerai par la partie paramètres.
Une petite vidéo de la navigation, assez rapide je trouve :
Une autre vidéo sur la partie JDB dynamique se rechargeant toutes les 10 secondes :
