Affichage des messages blog dont le libellé est Log4J. Afficher tous les messages blog
Affichage des messages blog dont le libellé est Log4J. Afficher tous les messages blog

lundi 16 juin 2008

Archetype 0.8 beta

After months of work, Archetype 0.8 beta is available, and the stable version is targeted for next week (or at least before the end of june).

Change log includes a lot of rewrites, more modularization, better loading system which ables to go from development to wide band production sites with almost nothing to change to get from one to the other, a proof of concept of Log4J like logging system, multiple template system handling( Basic, EJS, DOMTAL, ...) , heterogeneous template system handling for components, and I think I forget almost half of the feature we've done.

Swiip is focusing right now on giving more documentation for the 0.8 release, including a FAQ, more about Graphical Components, and so on.

Have fun !

mardi 19 juin 2007

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 :)

dimanche 10 juin 2007

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...)