Focus Technique : Le client riche, tout le monde en parle
La construction d'applications suivant les architectures N-Tiers s'affirme de plus en plus comme un standard de développement d'applications distribuées (Des clients distants – Des Middlewares serveur d'applications – Des serveurs de données ou de services).
Jusqu'à présent, la partie cliente est portée par un client dit « léger » (en fait un browser, essentiellement Internet Explorer, même si Mozilla FireFox fait une percée remarquable). En effet, celui-ci présente l'avantage d'être « nativement » déployé sur le Web.
Cependant, les projets intranet (voir extranet) ne peuvent pas toujours se satisfaire des faiblesses de HTML aux niveaux :
- des objets graphiques « complexes » (TreeView – Tableau à option de tri – Multi-tab – Graphique dynamique – Menu contextuel - etc.),
- des traitements des événements (Drag & Drop – Gestion des touches « Flèches » - Gestion des onglets – Click Droit – etc.)
- du traitement des validations de données (Saisie – Format)
- cache de données locales
Pour les clients qui peuvent se passer de Internet Explorer, il existe aujourd'hui (mais c'était déjà le cas depuis l'origine de JAVA à travers SWING, qui s'est révélé riche mais « lourd ») plusieurs voies prometteuses :
- XHTML du W3C (voir article correspondant dans cette newsletter) : Intègre la gestion complexe des formulaires (Validation – Contrôle de saisie – etc.), la gestion d’objets complexes, la gestion d’objets graphiques, la gestion d’objets de calcul, etc.
- SWT : C’est l’une des composantes de l’architecture de « base » de Eclipse. Plus légère que RCP Eclipse, elle est cependant limitée. C’est une solution qui peut se positionner pour un client « pas si riche que ça ».
- RCP ECLIPSE : Reprend l’architecture Eclipse complétée de PlugIn permettant de faciliter le développement d’applications à interface complexe. Tout est potentiellement permis (il reste encore beaucoup de choses à faire à la main) à condition de s'intégrer dans le « look » Eclipse. Bien dimensionné pour des applications avec une richesse graphique importante (sinon, l'infrastructure technique peut être lourde à intégrer pour un développeur & s'avérer pénalisante en performances pour des applications ne nécessitant que peu de besoins riches en graphisme ). Il existe peu ou pas d’outils RAD (cependant, il suffit de voir le dynamisme de la communauté « Open Source » pour ne pas douter qu'il en existera d'ici un ou deux ans)
- RCPLite : Comme son nom l’indique, il s’agit d’une solution légère (également en terme de possibilités) alternative à RCP Eclipse. Elle propose un FrameWork au dessus de SWT. Elle reprend le look & Feel de Eclipse. C’est une solution idéale pour construire des applications de type « Quicken ».
- FLEX : C’est la solution de MacroMedia en terme de client riche. Pour faire simple, elle est basée sur une description XML de la présentation (MXLM) et un serveur de présentation qui l’interprète et la transforme pour être lu par un client « Flash ». L’approche est séduisante, mais l’engouement des développeurs pour cette technologie est plus que limité.
- Open Office & UNO : Intègre dans un même environnement les possibilités bureautiques (Traitement de texte – Tableur – Dessin – Présentation – Requêteur SGBDR – Calcul – etc.) et un FrameWork (Universal Network Object) qui propose des interfaces permettant d’utiliser l’ensemble de ces composants
Ce qui est certain c'est que tout le monde en parle, beaucoup y travaillent, qu'il existe un certain nombre de solutions (lesquelles survivront ? même si l'on peut admettre que RCP Eclipse est le mieux positionné, d’autant plus qu’IBM le place au cœur de sa stratégie de construction du « nouveau » poste utilisateur à savoir « Workplace Client Technology Rich Edition - WCTRE ») mais que l'on est pas encore à l'ère de l'industrialisation (FrameWork « End Developpeur » & outil RAD).
C'est donc une affaire à suivre de près.
Étienne LOIEZ
Fermer |
Imprimer |
Contacts / Site |