Archetype's resolver

We've found that we needed a real brain storm about how we'll resolve modules URL and dependencies through configuration file.

Archetype.require is one of the oldest methods of Archetype. Many functionnalities have been added. To manage all configurations like "submodules", "needs", "aPath" and "rPath" we completed and complexified this method. It made it become a real mess and it's pretty hard to understand and maintain.

Configurations need a real recursive analysis but old require was not completely recursive (however you had to do a complex configuration to encounter any problem) and that's why we had that famous first bug on our JIRA: AJF-1.

I have extracted the resolution of modules names in the require parameter to correctly handle a recursive configuration and manage layers to order dependency loading.
Require is now really much more complete and robust and can handle any exotic configurations.

In the same evolution, I've seen that our UMN (Unique Module Name) object was used every time we needed to extract realPath or URL of the module. I transformed the $U function from returning UMN object to the URL String to simplify coding. It causes many internal refactoring but any changes for final user.

I've just committed these new functionality. It implies many changes like variables refactoring and jsdocs comment review but it's fully working.

Des nouvelles!

Après un mois de mai peu mouvementé, Swiip et moi même avons repris le développement.

Les priorités de Swiip sont:

• Finir les "require": synchrone (tout type de fichiers), asynchrone basé sur callback (idem), et asynchrone multiple basé sur callback(les deux 1ers sont presque fini).
• Commencer au plus vite la gestion de template (a minima avec celle de prototype, en rajoutant sans doute les boucles rapidement).

Les miennes sont:

• Créer au plus vite les outils d'émission/réception des évènements. Les utiliser dans Archetype, notamment remplacer les callback par des évènements dans le require.
• Mettre en place correctement tous les outils pour un développement propre : logger, évènements, tests unitaires, définition d'un composant (je reviendrai sur cette notion un peu spéciale dans un autre post, lorsque ce concept sera défini précisément ;) et mise en place de la structure pour en faire fonctionner.
  

L'avancement

La version 0.1.0 n'est pas loin de sortir...

Mon problème actuel est de gérer l'insertion de javascript via

Archetype.require(module)

En effet, pour que l'application ne dépende pas trop d'Archetype (j'aimerai ne pas emprisonner le développeur dans le framework ;o) ) il faut que ce require soit synchrone, c'est à dire qu'il charge le module, et que le programme attende que le module soit chargé dans le navigateur pour pouvoir l'utiliser.

Le gros problème, c'est que le javacript, c'est mono threadé, sans l'être vraiment. Quand j'ajoute une balise script avec la source vers le fichier js, celui-ci se charge en fond. Si je fais une boucle d'attente pour verifier qu'une variable vient de dire "ok, c'est chargé", je me retrouve en fait dans une boucle infinie.

Dans le bootstrap, j'utilise des setTimeout (qui, eux, ne sont pas dans le même thread) mais ceux-ci impose de pouvoir appeler une nouvelle fonction lorsque la variable est disponible.... Ce que je ne souhaite pas imposer à l'utilisateur ...

J'ai donc essayé la requête XmlHttpRequest synchrone (qui marche plus ou moin bien lors du chargement de la page... mais surtout il semblerait, qu'apres le chargement du script, de retour dans mon code d'initialisation, les objets que je viens de charger ne sont pas disponibles dans mon thread ! :'( Pour autant c'est peut-être un problème local au chargement de la page car le chargement d'une page est ce qu'il y a de plus complexe à comprendre en javascript, je crois :D

Mon premier Archetype.require est utilisé par le Logger qui utilise la configuration pour savoir quel module de logger il doit prendre, et en déduire quel type d'objet sera le singleton Logger (je vous rassure, ils ont tous la même interface abstraite!)

Bref, j'ai pas mal de tests à faire et je vais devoir enquêter plus loin sur comment fait le require de dojo (qui a, a priori, le même but).

Edit: Après enquête , dojo charge le javascript via une XmlHttpRequest Synchrone, mais au lieu de mettre le résultat de la requête dans une balise script, le code chargé est directement interprêté!

A tester, donc :)