Forums : Plateforme Mozilla

bonjour à tous, je poste ce billet avant de partir en vacance.

Depuis quelque années je me suis beaucoup investi sur la technologie XUL en mode Remote, J'ai développer une application riche à mon travail, et différents composants XBL certain disponible sur le WIKI.

Précurseur de cette technologie au seins de mon entreprise, j'ai même il y deux ans fait une présentation à l'ensemble du pôle de développement. Hélas, Mozilla et sa politique de ne promouvoir que Firefox, n'a jamais communiqué réellement sur la Technologie XUL.

Pour preuve, lors des matchs dans la presse spécialisée des différentes alternatives pour le RIA, FLEX et Silverlight caracolent. Parfois javaFX aussi. Pas de XUL dans les 01 info ou autres magazines que les decideurs lisent (Sans rien comprendre le plus souvent d'ailleur).

XUL à une réputation de Geek techno. A tord je penses, au vue du nombre de Firefox "deployés" dans le monde utilisant ce framework.

Donc ce qui devait arriver est arrivé. Le pôle de développement à décidé de faire un choix quand a la technologie pour nos RIA. Évidement, je vous le donne en mille, FLEX fut choisie. (il sont fort chez Adobe). J'avoue avoir était déçu de ce choix, mais l'on dira pas de moi que je suis un vieux con à peine 34 ans..., et quand on m'a demandé d'étudier la réécriture de mon application en FLEX, je m'y suis mis de bon cœur.

Voila pour l'historique. Je voulais commencé par ceci, pour montrer l'objectivité des propos qui vont suivre. Je retiendrais donc en vrac :

• Le language de script : javascript ne tient pas la comparaison par rapport à actionscript. language typé, scope (private, public) des methodes et des variables...

• l'IDE inexistant pour XUL. Surement le point le plus critiquable. l'IDE Flex même si payant est très agréable, même avec ses lacunes. je parle même pas du mode design en pratique inutile, mais de la complétion, la coloration syntaxique et finalement les erreurs signalées grâce pour le coup à la compilation nécessaire.

• Au niveau développement, j'avais un peu peur au début des recompilation nécessaire à Flex, mais finalement pas si contraignantes. Mais vaut mieux penser à faire la partie authentification, à la fin du développement sous peine de devoir se taper toute la phase d'authentification pour chaque modification de vue... car le F5 ca marche pas pour une application Flex..

• XUL, est Web Friendly. Et peut se comparer à une extension de XHTML. Il permet d'embarquer toute les technologies du WEB, comme du Flash d'ailleurs ce qui n'est pas vrai pour l'inverse.

• Flex malgré ca soit disant licence Mozilla, s'il s'intègre aisément dans les technologies Web, ne sais pas du tout, mais pas du tout faire le contraire. GROS Point noir pour FLEX. En effet, nulle moyen d'afficher ne serait ce qu'une page HTML dans un application Flex. Oui, je répète le Framework FLEX ne permet pas cela. En gros pour les XULeur, il manque cruellement un composant iframe au framework Flex. Il existe il est vrai des solutions, mais c'est plus au moins de la bidouille avec un système d'iframe à l'extérieur du "swf" (flash résultant de la compilation de code FLex).

Quand je pense que via une extension comme IETab, on arrive à utiliser le rendu d'Internet Exploreur dans Firefox, En flex, seule l'utilisation d'un HTML reformaté à la sauce Adobe peut etre affiché nativement dans une application Flex.

• Un composant mx:HTML tentant de résoudre ce problème existe cependant dans AIR, la solution standalone de Flex (l'équivalent de XULrunner). Mais ce dernier est basé sur une version très simplifié de Safari (bon navigateur au demeurant) et ne permet d'afficher que du HTML, du PDF et des images. surement du Flash (non testé). Ce que j'entends par là c'est que nulle moyen de demander à l'OS d'ouvrir ne serais ce qu'un word. Bien sur il y a toujours le moyen de déchargé cette tache au navigateur par défaut en utilisant la méthode navigateToURL(...). Mais cela sous entends que l'on risque de devoir gérer plusieurs session, puisque le navigateur par défaut ne partage pas la session de safari. Sans parler de l'ergonomie douteuse que l'utilisateur subira quand il cliquera sur un word, qui ouvrira FF ou IE qui lui demandera si il veux ouvrir ou enregistrer le doc, et enfin qd word enfin s'ouvrira avec en prime une fenêtre du browser ouverte et vide.

• XUL avec XUlRunner ou un script signé permet d'accéder à toute les ressources de la machine hôte. Chez Adobe, les règles de sécurité, c'est trop compliquées à gérer. on fait un sandbox et basta, vous accédez à rien d'autre. Même dans une application AIR, vous n'avez par exemple pas moyen de déployer un API qui aurait une tache bien précise (décompression, calcul...). Vous imaginez, les contraintes d'une application standalone (déploiement, intallation, maj), sans les avantages... n'importe quoi. Nulle moyen non plus de lancer une application tierce sur le client.

• Avec XUL, vous benéficiez de toute la puissance de Gecko rendu HTML bien sur, mais SVG, MathML, CSS, XUL, XPath, RDF, et j'en passe. Chez Adobe, on réinvente tout. le CSS est incompatible, l'API de d'accès au XML ressemble comme deux goutte d'eau a Xpath, mais n'est pas compatible, le SVG n'est pas supporté mais un commerciale de Adobe, m'a dit que Adobe était en train de développer leur solution (bien sur).

• Autre exmple, pour implementer la correction (indication des fautes de syntaxe) dans vos RIA Flex, vous attendrez gentiment que Adobe le fasse (c'est prévu évidement). Alors que en XUL, l'insertion d'un textarea, bénéficiera de la correction de Firefox.

• Je trouve que la création de composant XUL via XBL est plus séduisante que celle de Flex. En fait, Adobe à été plus pragmatique sur ce point, et n'a pas réellement créé un atre language pour cela, ce qui est bien en soit, mais malgré l'absence de pouvoir définir les notion de public/private pour les attribute et les methode du composant créé, je préfère XBL qui permet entre autre d'insérer des nœuds fils à différent endroit du content du composant. En Flex, vous devez déclarer un variable public qui recevra les noeuds fils que vous voulez inclure dans le composant, ce qui est domage, c'est qu'un composant maison ne donne pas toujours l'impression de se comporté comme un composant du framework. (Enfin, je suis conscient que sans exemple c'est dur de comprendre... LOL).

• Idem pour les templates, je trouve plus puissant le système de template de XUL, même si au final, c'est moins souple. RDF, est un tres bon descripteur de ressource. Même si certain le trouve un peu complexe à appréhender au début. Une fois compris, on peut plus s'en passer.

• Comme le flash player ne communique pas avec l'OS, pas moyen de profiter des codecs installés sur celui ci, donc avec Adobe, si je stream une vidéo avec un codec exotique, j'ai juste à prier que Adobe l'inclura dans la prochaine release. Ou alors, il faut que je la convertisse coté serveur. J'adore...

• Après mon entrevue avec un commerciale de Adobe, ce que je retiens, c'est que Adobe veut tout refaire à sa sauce. Je pense que leur but inavoué est de supplanter JAVA dans l'embarqué. Peut être même un jour faire un OS basé sur Flash. En contrôlant et en développant toute les technologie du WEB. En etant pas compatible avec les autres bien sur, mais à leur corps défendant en proposant des solutions que d'autre n'ont pas su proposer (Flash pour l'animation, IDE complet pour Flex). Vous étonnez pas si demain il y aura un lecteur FLash dans votre TV, machine à laver etc...

Que dire de plus, je viendrais surement rajouter des choses si d'autres choses me viennent à l'esprit. Je vous invite à faire part de vos expériences aussi. Loin des guerres monde libre/microsoft, j'avoue être impatient de voir réellement silverlight en action avec leur propre IDE. J'étais très enthousiaste aussi par JavaFX, la solution de Sun, mais j'ai pas l'impression que la description de l'interface ce fasse par une description XML. Ce qui est quand même la raison première de XUL/Flex/Silverlight à mon sens.

Enfin pour finir, je fait un appel à Mozilla :

• Communiquez plus sur votre excellent Framework.
• Integrez rapidement une version de javascript plus en adéquation avec les language actuels (Class Interface, typage, public private etc...).
• Sautez une realease de Firefox, mais bon sang de bon soir, faite un IDE digne de ce nom, sur Eclipse par exemple.
• Installé Xulrunner lors de l'install de FireFox.
• Enfin, un composant natif RTE serait le bienvenue. J'avous que Midas m'a laissé perplexe, on sens qu'il manque de maturité. Mais le principe est bon. Il faut juste améliorer l'API.