Asynchronisme vs Evenementiel

Depuis le début de nos dev, deux modèles s'opposent sur lesquels nous n'avons pas encore réellement tranché : l'asynchronisme et l'événementiel.

• Optique Asynchrone
  

Quand on fait un peu d'Ajax on apprend vite à faire de l'asynchronisme. En JS la fonction est une variable (presque) comme un autre. On lance une méthode qui rendra sa réponse dans un temps indéfini, on passe en paramètre la méthode que l'on veut qui soit lancée lors de la réponse et c'est parti.

Pour avoir fait tout le require de cette façon, je me rends compte que même si c'est un peu déstabilisant, on apprend à jongler avec les objets fonction et on s'en sort pas trop mal.

Une problématique existait : le join de plusieurs asynchronismes parallèles. Problématique résolue avec le système Archetype.Joiner.

• Optique Événementielle

Dans les applications lourdes, on utilise souvent de préférence des systèmes d'évènements. On lance une méthode qui est asynchrone, elle déclenche un évènement quand elle a finie.

Si on veut faire quelque chose après, on s'identifie comme "listener"de l'évènement et notre méthode sera exécutée tout aussi bien qu'avec la méthode asynchrone.

• Et la question...

Et la question qui suit est : qu'est ce qui est le mieux ? Nous savons que nous utiliserons énormément à terme les évènement car nous voulons que nos composants puissent déclencher tous les évènements les concernant sans avoir à savoir si d'autres composants sont à l'écoute ou non.

Mais pour autant, le require géré en asynchrone est-il à refaire avec des évènements ? Y-a-t-il une solution meilleure que l'autre ?

Dans tous les cas, l'utilisation importante d'évènement me semble nécessiter une organisation forte pour le nommage d'évènement. Ce sera un chantier important à venir.

Loader

Le modèle du require a pas mal évolué depuis quelques temps, je vais détailler son architecture actuelle.

• UnifiedModuleName

Tout d'abord, pour améliorer la gestion des XHR il a fallu faire une gestion construite de ceux qui avaient déjà été réalisés et de ceux qui ne l'avaient pas été.
Pour cela nous avons créé notre propre système de notation permettant de façon unique d'identifier un fichier sur le serveur et de quel type il est afin de savoir comment l'interpréter une fois chargé.
Cela a peut être l'air simpliste, mais quelque soit la notation de l'utilisateur du framework, identifier de façon unique chaque fichier s'est avéré un vrai besoin.

• Require

Le Require est devenu maintenant seulement la première étape et la porte d'entrée du système. Son rôle est d'identifier chaque fichier et de vérifier s'il n'a pas été déjà chargé. Il envoie ensuite la requête au loader.
Le cas des requires synchrones est particulier, il les gérera alors sans le loader.

• Loader

Le loader représente la réelle nouveauté du système. Il s'agit d'une fonction sur laquelle rebouclent tous les XHR asynchrones. On peut utiliser la fonction de deux façons : soit pour ajouter des XHR (depuis le require) soit pour en signaler des réalisés (en callback des XHR).
Ainsi le loader gère une file d'attente de tous les XHR, il également à même de déclencher les callbacks dans le cas des requires multiples.
Avec ce système, tous les XHR rebouclent au même endroit et la gestion est centralisée. Cela permet notamment la possibilité de gérer des priorités au niveau des chargements ainsi que de laisser des "slots" d'XHR pour la partie métier de l'application.

• XHR

Le lancement lui-même des XHR représente la dernière partie du système. Elle n'a par contre pas énormément évolué.

• Synchrone & Asynchrone

Nous avons malheureusement découvert un bug dans le système. L'imbrication d'une requête asynchrone et d'une synchrone nous a donné des résultats hautement improbables sur FF sans que nous ne puissions comprendre ce qu'il se passait. J'en arrive malheureusement à la conclusion que nous n'y pouvons rien.
Mon coté extrémiste dira même que la requête synchrone devrait être abandonnée totalement mais j'avoue qu'elle semblait bien intéressante pour s'assurer de la présence d'une librairie avant un code.

Templates codés

Cela fait quelques temps que je n'avais pas posté et pourtant le code a bien avancé.

Les templates tout d'abord. La classe Template (que je renommerai bientôt Archetype.Template) fonctionne maintenant. La syntaxe est plus ou moins celle de Smarty que j'apprécie de par sa simplicitée et par le fait qu'elle ne fait pas d'ingérence dans le model XML.

Le source est très simple grâce à la fonction eval de JS et permet également que tout ce qui se trouve dans les accolades soit réellement interprété facilement comme du code JS.

Actuellement, l'affichage de variable, la condition (sans else) et la boucle for sont implémentés. Il sera possible d'enrichir mais la plus grande partie des fonctionnalités est possible.

La syntaxe TAL que défend très bien Temsa a beaucoup d'attraits et je ne exclue pas du tout l'intégrer dans l'avenir. La version actuelle permet cependant d'avancer.