Dans le cadre d'une refonte technique de son application de gestion des contrats & des plannings hebdomadaires mise à disposition de ses magasins sur un Extranet, notre client a demandé à SALTO d'encapsuler la complexité des JavaScripts (Pointer/Glisser - Déplacer - Annuler - Créer les tâches d'un planning) & de réaliser les « images » des plannings non plus en SVG, mais en HTML.

Pour cela, SALTO a utilisé son FrameWork de Présentation basé sur les spécifications WebFORMS.
Son architecture repose sur un enrichissement des verbes HTML 4.0 (dont le vocabulaire est compatible avec celui de WebFORMS)
Ceux-ci sont pris en compte par une fonction JavaScript qui dispatche vers le composant JavaScript implémentant la fonctionnalité représentant le verbe (voir schéma ci-après).

D'un point de vue développeur, il n'y a plus a programmer en JavaScript mais à positionner des «Tag» sur la page HTML représentant :

• le composant «complexe» (TreeView - StyleSheet - Barre d'histogramme - etc.) et ses attributs complémentaires (Obligatoire - Format de saisie - Flèche Haute - Flèche Basse - Accélérateur «Ctrl» - Longueur maximale de saisie - Passage automatique à la zone suivant - etc.)
• le comportement à implémenter (Pointer/Glisser - Déplacer - Annuler - etc.)

Bien évidemment, il peut exister des composants ou des comportements «spécifiques». Il s'agit alors pour l'architecture responsable du FrameWork de Présentation, d'implémenter le binôme «Tag - Fonction JavaScript» (en s'assurant du respect des spécifications WebForms) afin de mettre à disposition des développeurs le «Tag» sans que ceux-ci n'aient à se soucier d'implémenter une fonction JavaScript.
C'est ce qui a été réalisé par SALTO dans le cadre de ce projet pour implémenter les spécificités liées à la représentation ou aux événements d'un planning.

Enfin, le client a également demandé une compatibilité IE X (X>5) et MOZILLA FIREFOX.
C'est ici que tout se complique.
En effet, WebFORMS dans ses spécifications s'est rendu Full Compatible les événements XHTML. Par contre, IE, dans sa version actuelle (cela doit changer avec XAML) traite à sa façon certains événements.
Il a donc fallu créer une bibliothèque « JavaScript » pour IE afin que le même « code » HTML enrichi puisse être exécuté indifféremment sur IE & FIREFOX.

En synthèse et pour mieux visualiser le résultat voici 2 copies d'écran représentatives de ce que le projet représente en terme d'ergonomie :

Exemple d'écran réalisé avec SVG


Exemple d'écran réalisé avec HTML seulement

Que peut-on retenir de ce projet ?

1. Qu'il est possible de réaliser des composants complexes en HTML – JavaScript (mais cela tout le monde le sait) sans qu'un développeur ait a manipuler JavaScript. Il s'agit pour lui l'utiliser des balises & attributs complémentaires
   Conduite du changement minimisée par rapport à des solutions XHTML qui mettent en œuvre des nouveaux concepts (Structuration d'un Formulaire à travers du XML par exemple)
2. Que la solution répond aux besoins de complexité ergonomique tout en restant compatible avec HTML 4.0
   Pas besoin de migrer les applications Web existantes
   Pas besoin de déployer un client riche
   Pas besoin de mettre en œuvre une solution RCP en vogue actuellement (mais dont l'état de maturité est faible, il suffit de voir les différentes solutions émergeantes dont on ne sait pas bien la(es)quelle(s) l'emportera(ont).
3. Qu'il existe une spécification «WebFORMS» pouvant entrer dans le W3C, qu'il est possible d'implémenter sans investissements de recherche & développement insurmontables (SALTO en a implémenté une partie à travers son FrameWork de présentation)
   Même s'il n'existe pas d'implémentation de référence à ce jour de «WebFORMS», il y a fort à parier qu'elle existera rapidement et qu'elle pourrait bien avoir un véritable succès, pas seulement d'estime et par conséquence se positionner comme le futur HTML 5.0.
4. Que la compatibilité IE - FIREFOX reste véritablement un problème épineux quand on désire manager des événements «complexes» (Le Drag & Drop en étant un exemple.)
   Espérons que MicroSoft & le W3C s'entendront sur un minimum commun que pourrait être le futur HTML 5 dont le challenger en terme de spécification le plus sérieux (voir l'unique) est «WEBFORMS».
   
   

Etienne LOIEZ