"La rentrée" !

We have passed some busy summer holidays, and some announcement will come in the next few days. No comment, the content is a surprise :)

As 0.8.0 beta was based upon the (quite deprecated now) Prototype 1.5, the current "tip" works perfectly using now Prototype 1.6.

We originally made a branch in order to implement Prototype 1.6 compatibility as an experiment for the 0.9.0... But I've "mis-committed" (I've stupidly clicked on the bad repository when pushing the main changes) it on the current tip and continued with it.

The 0.8.0 was at this moment quite ready for a release, but we wanted to document a lot more the use of the framework itself. However, my job is to read and correct the documentation and I prefer a lor more coding than correcting a documentation, so... We did not release during the summer.

However a release is yet ready to go out, but based on Prototype 1.6. It has been quite heavily tested, even on the brand new Chrome, and we are hapopy with the result yet. But yet again we lack of documentation for this new release.

So, I think we will release the 0.9.0 before the 0.8.0 final(!!), because getting the 0.8.0 back from the history, test it, etc. will just be a pain compared to the 0.9.0 release.

Between the 2 releases, the main change is jumping from Prototype 1.5 to Prototype 1.6, we have added some handy tools in the 0.9.0, notably for playing easily with URLs.

Now what do we plan for 1.0 ? It depends. We have purposed an internship in our company focused on working on Archetype, in order to give it some cool tools to help for high trafic website, notably to minify the number of hits for loading the page (so mostly helping for bundling JavaScripts, and maybe help for CSS Sprites).

We have started in 0.8.0, the ability to choose what you want for specific part as a backend. We would like in the future version not to rely just on Prototype, but on any good framework we can use as a backend. We have just started a "secret" JQuery branch in order to see what is possible.

Other good news : a cool new open source project about social bookmarks relying only on Archetype to render the application should be there in some months. We've got a cool working beta version of it at Atos Worldline, but we have to do some work in order to release it as a free software ( we mainly have to avoid the use of our SSO for login). The main author of this project has written a very cool JS Code and I hope to convince him joining the Archetype Team :)

Again using Archetype, I've made a "plug&play" (call it widget if you want, but it's not exactly a widget) system in order to use a Solr ( http://lucene.apache.org/solr/ ) as a cross-domain search tool, that you can use on any web page that has a little form with an input and a submit event. I am working now on integrating Opensearch with it if it's possible.

We are very happy with Archetype can do yet, and we hope it's the same for you!

Prototype 1.6 compatible :)

The new branch for prototype 1.6 is now ok and runs Slidy smoothly, which is a good test application !

I think the patch will be integrated for the 0.9.0 but we still have to do some work for 0.8.0 release before :)

After the 0.9.0 release, I may maintain a Prototype 1.5 compatible version, thanks to Mercurial :D

P.S.: I've mis-pushed the prototype 1.6 patch on the current official tip... will remove it ASAP !

Much more documentation and Prototype 1.6 coming

Ok, it's a while I've not posted here (again !) but we're still working on Archetype, don't worry :)

Swiip has made so much documentation for 0.8.0 (you can have a look at http://archetypejs.org/snapshot ) that we had to push the 0.8.0 release to some other day in order to do all the checks and reviews needed.

Have you ever wanted a Prototype 1.6 compatibility ? It's almost available on one of my test repo, just pull http://freehg.org/u/temsa/archetype-p16/ with your Mercurial client and try to help me (Slidy is not working right now, and I don't understand why) ;)

Using Archetype as a dependency manager only

After a whole day work, I've modularised Archetype bootstrap dependencies in order to load just what is needed to use Archetype as a "Script Loader" only.

It has been tested this evening on a big project using about hundred of interdependent files successfully without any modification of the framework itself! It's available in the SVN trunk right now :)

This project based upon OpenLayers, with a lot of enhancement using multiple overloading classes files). This project does not use Joiners, nor the Event system, not the Archetype.Class enhancement.

There are now some "expert settings" in the configuration, giving you the ability to load and use only what you need.

This is a great news as Archetype starts to be very very strong on the dependency management side and can be easily used now on any Prototype 1.5.x based application (or not, but it just relies on Prototype 1.5.x).

In a script loading only configuration, the framework takes about 34kb totally uncompressed (with a lot of comments for JsDoc).
Using a JSmin(a basic JavaScript compressor) pass, it shrinks down to 15kb, and if your using the HTTP1.1 GZip compression on your web server, it's no more than a 4.8kb that will be used to go on the client!

Awesome, isn't it ? ;)

The Prototype 1.6 headaches

You may have notice that we haven't switched yet to Prototype 1.6.x.

There are many reasons to this, and the main one is that Prototype has broken the compatibility ( http://prototypejs.org/api/hash ) with the original Hashmap format. This leads to some problems as we are used to enhance basic Hashmap to prototype ones when needed, particularly for the whole files loading process...

We often use hashmaps to define namespaces, and the new hashmap format leads to a particurlarly bad (for this purpose) new syntax to acces members.

We're looking for some good ways to handle this, and the new $H instruction (compared to the old one) has some interest: it's quick, make a "copy" of the original map (in facts it keeps the same reference to objects, and just copies strings and numbers) and gives a good way to come back to an "plain old" hashmap after prototype functions has been used.

So I'm working to find a good solution to use Prototype 1.6, and I even think of changing some backends (like object creations and custom events) to Prototype 1.6 ones. Not very easy to say at the moment whether I'll do this or not.

Présentation

Archetype est un framework javascript. Oui, un framework : il est loin de la simple librairie ! Par contre il est basé sur des librairies d'excellente facture pour lui servir de base, comme le sont Prototype et Scriptaculous.

Ce framework vise à permettre de créer des applications réellement "web 2.0" en offrant une suite de services indispensables pour avoir des logiciels de bonne qualité géré principalement par javascript.

La logique métier et la sécurité restent gérés côté serveur, mais tout le reste (vue et contrôleur, soit aucune donnée sensible) peut passer côté javascript, ce qui permet de fabriquer des applications plus fluides, plus rapides et d'améliorer fortement l'expérience utilisateur en lui fournissant de vrais applications riches dans un navigateur Web, lui permettant de profiter de tous les services que celui-ci peut apporter.

Il offre les services suivants:

• Gestion intelligente des dépendances, et chargement de l'ensemble des fichiers du projet pour la page chargée : sur les projets chargés en javascript il est courant d'avoir des problèmes de chargement, aussi Archetype vise à résoudre ces problèmes de manière simple et efficace.
  Un site typique utilisant Archetype possède une page principale pratiquement vide, ne contenant qu'un header avec une balise script incluant archetype.js. Tout le reste est géré par Archetype automatiquement.
• Améliorations des systèmes objets du Javascript : héritage, singleton, appel des méthodes parentes, fonctions importées, etc.
  
• Un système de log configurable : quel utilisateur de Log4J ne trouve pas un manque dans la possibilité de logguer proprement des informations afin de permettre un debogage aisé de l'application ? Plusieurs logger sont disponibles dans le framework, suivant les besoins, et géré simplement par configuration.
  Certains s'appuient sur Firebug, d'autres sur des fenêtres de débogage en javascript, d'autres encore basé sur des alertes, enfin il existe évidemment un logger sans sortie afin de permettre une mise en production aisée.
  
• Un système de template html (ou tout autre format basé sur du texte): il interprète (très rapidement) en javascript, et permet ainsi de gérer parfaitement un Modèle Vue-Contrôleur, basé sur un syntaxe très proche de Smarty (d'autre format, tel que TAL est aussi à venir).
  
• Conteneur léger : un des concepts les plus forts d'Archetype.
  Ce système de conteneur (appelé Component) offre de nouvelles possibilités au développement javascript: description des dépendances et chargements automatiques de celles-ci, stabilité du "this" dans l'objet, services transversaux automatisés basés sur des conventions (et/ou des configurations), proxy pré/post méthode de l'objet, permettant par exemple des log plus ou moins détaillés suivant l'objet et la configuration ( façon Log4J) ou encore d'émettre/écouter simplement les événements concernant l'objet.
• Widgets réutilisables : basés sur les "Component", les "GraphicalComponent" permettent de rassembler en un concept simple, un ensemble de fichier css/html/javascript, en widget réutilisable de page en page et de projet en projet.
  C'est la base d'une interface utilisateur modulaire, efficace, et facile à réaliser, basée sur un Modèle Vue-Contrôleur pratique et efficace.

Le projet Archetype a pour but d'offrir au développeur web tous les outils pour travailler en Javascript comme avec les framework serveur, mais sans cacher ce Javascript dans une couche serveur qui s'avère toujours trop simple pour pouvoir réaliser ce que le client désire.

Archetype offre donc un véritable environnement de travail au développeur, en utilisant les principes des meilleurs outils connus actuellement dans le domaine du développement web et favorise l'utilisation de pratiques reconnues dans un langage qui était alors dépourvu de toutes ces structures qui sont pourtant indispensables à des applications de qualité et faciles à faire évoluer et à maintenir.

Ca bouge !

Voilà quelques jours que nous n'avons rien dit ici ... Mais ça bouge beaucoup sous le capot d'Archetype.

Par contre, on ne respecte pas du tout les ToDo pour le moment ... !

Alors, tout d'abord, Swiip nous a fait un magnifique moteur de template "à la smarty", il est très bien et pas gourmand en ressource :)

Sinon on a trouvé un moteur javascript de template, reprenant la syntaxe de TAL ( le, à mon humble avis, superbe système de template de Zope), utilisant le DOM pour aller vite et se simplifier la vie... Mais celui-ci requiert que le template soit directement inséré dans le dom pour créer le html, ce qui me gène un peu. Il faudrait insérer le template dans une balise html cachée pour interprétation avant de la copier dans le html visible pour qu'elle soit satisfaisante, ce qui ne me parait pas super propre :/

Ce moteur est testable ici : http://www.heute-morgen.de/test/domtal.html regardez le fichier javascript si vous êtes curieux de voir comment ça marche :) Un merci a Joachim Zobel d'avoir créé cette petite librairie, je pense que nous le contacterons en temps voulu si on trouve une manière adéquate d'intégrer son code pour un moteur de template en TAL :)

Les templates montrant le bout de leur nez, nous avons naturellement commencé à regarder comment les inclure élégamment dans le code.

Swiip est encore en train de faire des modifications sur le require pour gérer au mieux les inclusions d'inclusion d'inclusion ... etc.

Pour ma part, je mets les mains dans le cambouis aussi sur une des fonctionnalités les plus importantes d'Archetype: les composants (peut-être s'appeleront-ils archetypes dans un futur où ils seront achevés de penser/coder).

Qu'est-ce qu'un composant ? C'est un outil pour faire du M.V.C. (Modèle Vue Contrôleur).

Rien de pire que de mélanger le code et la structure dans une application. Grâce aux templates, nous pouvons gérer une vue, que le contrôleur chargera quand on l'instancie. La vue peut représenter une page entière, un bout de page, et si l'application est correctement découpeé, la vue ne contient jamais grand chose sinon des inclusions d'autres vue/contrôleur (ici c'est l'inclusion d'un composant).

Ceci parait bien compliqué à instancier et pourrait s'avérer lourd à utiliser. Mais on code un framework, notre but est donc de faciliter la vie du programmeur et de lui offrir de nouvelles possibilités :)

Dans Archetype, un composant est donc un fichier JS décrivant les dépendances qui lui sont nécessaires, et une fonction "main()" appelée lorsque le composant a toutes ses dépendances à disposition.

Mais on ne s'arrête pas là. Archetype créé un composant à partir de cette description. Comme c'est lui qui a la main et qui construit l'objet il peut facilement rajouter des services et des méthodes à l'objet constituant le contrôleur du composant.

Aussi, en se basant simplement sur l'objet décrit, on va pouvoir lui rajouter, grâce aux noms des fonctions le composant, des services utiles, divers et variés:

• On pourra changer le logger par composant (via configuration, façon Log4J).
• On pourra faire de l'inversion de contrôle (via configuration, comme Spring)
  
• On pourra préfixer, composant par composant, méthode par méthode et automatiquement, la sortie du logger, pour facilement savoir où se trouve un problème.
  
• Toutes les fonctions commençant par "on" réagiront a l'évènement décrit par le nom, suivant la syntaxe :"on"+nom de l'évènement (exemple: "onShoppingCartAddProduct") et seront automatiquement "bindé" comme event Listener(en utilisant dans la construction de la fonction, le fameux bindAsEventListener), permettant d'utiliser "this" dedans sans le décrire explicitement.
  
• Toutes les fonctions commençant par "send" seront enregistrées dans "Archetype.Events" comme fournisseuse d'évènements. On pourra même utiliser une fonction vide si la fonction ne fait qu'envoyer l'évènement en lui passant les paramètres de la fonction. Par exemple, pour le composant ShoppingCart, on pourra créer la fonction:
  sendAddProduct: Prototype.emptyFunction(productId,quantity)
  
• avant ou après chaque appel à une méthode, on pourra configurer l'appel de fonction, basé sur une configuration (logger, gestion du mode offline de manière transversale, etc.)
  

Bref, les composants sont une sorte de Tapestry/Struts + un Spring éventuellement :)

Donc voilà, de gros gros développement en cours en ce moment, de quoi donner un vrai coeur a Archetype :)

Template JS !

Voilà qui est lancé, un premier jet du moteur de template est parti.

Cela sera inévitablement une des bases d'un système Web côté client. Après des années de jsp, de php, de smarty et j'en passe, il est peu concevable de faire du Web en collant des bouts de code HTML dans des chaînes de caractères JavaScript. Tous les langages que je connais ont une syntaxe plus ou moins approfondie de template HTML. Hé bien, cela le sera aussi en JavaScript.

Nous avons trouvé un ou deux moteurs déjà implémentés en JavaScript même si c'est un concept auquel peu de gens semblent s'intéresser. Mais on ne peut pas dire que leur code source soit limpide et nous aimerions quelque chose que nous puissions faire évoluer à notre gré.

Nous avons choisis de partir sur les bases de l'objet Template de Prototype, cela a l'avantage de nous donner la possibilité de proposer l'évolution à Prototype directement quand elle sera ok.

Pour finir, le système de prototype se base sur des regexp (m'enfin sûrement tous les moteurs le font mais bon...), j'espère qu'il sera possible à terme de pouvoir proposer le même moteur avec différentes syntaxes de template pour arranger ceux qui ont leurs habitudes avec certains langages de templates.

En tout cas, on a déjà les bases d'une boucle et d'une condition, il va être possible d'avancer rapidement de ce coté.

Mon but est maintenant de peaufiner mes deux bébés à savoir le require et les Templates qui seront la base de la structure de Composant dont les contours se dessinent de plus en plus précisément.

Un logger ?

Tous les adeptes de Firebug connaissent un de ses principaux intérêts : le Logger (console.log), permettant de programmer sans mettre des "alert" de partout dans le code !

Aussi j'avais dans la volonté qu'Archetype gère différentes façons de logger facilement (changer dans 10 fichiers d'en-tête firebug pour firebugx n'est pas pratique à mon avis, même si en théorie on n'a jamais tant d'en tête... sauf pour un site avec des mises en page très différentes).

A noter que prototype window fournit aussi un système de log, ça pourrait être sympa à intégrer comme logger, idem pour le logger d'event des custom Events.

Donc voilà, le Logger est instancié au début de l'application, utilisant la classe indiquée dans la configuration. Ça marche très bien avec le logger 'Null' et le 'Firebug'

J'aimerai atteindre un niveau de configuration permettant de travailler comme avec Log4J. J'ai eu quelques idées là-dessus il y a quelques semaines mais j'avoue qu'elles m'ont échappées depuis, si vous avez une bonne idée, je suis preneur (si possible, quelque chose de non intrusif au niveau du code...)