mercredi 5 septembre 2007

MethodBuilder !

Mais qu'est-ce donc ?

Pour expliquer le principe du "MethodBuilder ", il faut expliquer le principe de la construction des "Components".

Pour construire un "Component", on prend une définition, c'est à dire tout simplement une map Javascript. Cette définition contient les méthodes que l'on souhaite voir intégré dans l'objet.

Un des avantages de maîtriser la construction de ses objets c'est qu'on a pour chaque méthode 2 informations :
  • son nom
  • la fonction que le développeur souhaite exécuter
Tout cela paraît bien basique, et pourtant ! Le nom décrit beaucoup de chose puisqu'il indique souvent le but d'une fonction. On peut donc apporter des services autour d'une méthode en se basant sur son nom.

Une propriété du javascript est qu'il est facile de faire une fonction "proxy" dans un objet, c'est-à -dire une fonction qui va englober la fonction d'origine, prendre les mêmes paramètres, lui transmettre, et manipuler le contexte pour faire croire à la fonction appelée qu'elle a été appelée directement (on force simplement le "this" à correspondre au "this" qu'on veut !).

Le MethodBuilder permet donc d'utiliser les conventions de nommage pour déterminer ce que l'on souhaite comme service pour une méthode.

Un MethodBuilder consiste donc en un objet composé d'une expression régulière, et d'une méthode de création de fonction.

En l'état, il y a 3 MethodBuilders :
  • public&private : s'applique à toutes les méthodes. Les méthodes préfixées par '_' sont considérées comme privée et sont inaccessible via "objet.methode" mais le sont par "this.methode" dans l'objet
  • listener : toute méthode préfixée par "on" est automatiquement inscrite sur le broker comme listener d'un évènement, dont le nom correspond à la suite du nom de la méthode. onHelloWorld sera donc appelée chaque fois que l'évènement "HelloWorld" sera levé.
  • sender : toute méthode préfixée par "fire" sera automatiquement enregistrée comme fournisseuse d'évènement sur le broker dont le nom correspond à celui de la méthode privé "fire" (this.fireHelloWorld enverra un évènement HelloWorld, avec pour donné le premier argument passé en paramètre de la fonction). Actuellement la fonction d'origine décrite dans la définition du composant n'est pas utilisée, et est remplacée par une fonction envoyant l'évènement. Il est probable que la fonction d'origine soit appelée après l'envoi de l'évènement dans un futur proche.
Le MethodBuilder permet donc d'exécuter un travail transversal sur les objets. Le prochain MethodBuilder que je souhaite fabriquer est un logger par composant dont le rendu et la verbosité sera définie par défaut dans la définition de l'objet, et surchargeable par configuration (bref, l'idée est d'avoir un vrai "Log4JS" permettant de définir la méthode d'affichage et le niveau d'information à afficher suivant l'objet, voire même sa méthode).
Un autre avantage de ce système est qu'il permet au logger de connaître le nom de la méthode et de l'objet dans lequel il travaille, et ainsi de les indiquer lors du log (comme peut le faire Log4J d'ailleurs).

Actuellement, tous les MethodBuilders sont appliqués à tous les Components. L'amélioration de ce concept est de faire un système de configuration permettant d'activer/de désactiver des MethodBuilders suivant le Component, intégrées dans la configuration de celui-ci (en même temps que les dépendances) et surchargeables via une configuration centralisée.

Bref, c'est prometteur, et ça devrait permettre beaucoup de services sympathiques :)

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.

mardi 4 septembre 2007

Compatibilité IE et Safari :)

Voilà bien longtemps qu'on n'a pas donné de nouvelles, et pourtant le développement est très loin de s'être arrêté, puisqu'on se rapproche à graaaands pas d'une version publiable (pas une 1.0, mais une 0.1 de bonne facture :D ), on prévoit sa sorti d'ici fin-octobre (pas de date précise, on le fera "quand ce sera prêt").

Tandis qu'Archetype fait son petit bonhomme de chemin dans Atos Worldline, qui nous emploie aussi bien Swiip que moi, société grâce à qui nous avons un temps dédié pour développer le framework (un jour par semaine !) et des opportunités de tests dans des applications internes (on intègre actuellement Archetype dans une application web développée en parallèle en Flex ), les "features" de la 0.1 se précisent et il va me falloir penser à changer l'article 'présentation' qui est actuellement un peu à côté de la plaque(EDIT: c'est fait :) ).

Aussi, on commence à régler les derniers bugs comme les problèmes de compatibilité (en fait il s'agissait d'une histoire de scope dans eval et d'une virgule en trop dans une Map) aussi nous avons pu lancer complètement une application composée de plusieurs graphicalComponent (des widgets, si vous préférez) aussi bien sous Firefox 2.0, que IE6, IE7 et Safari 3 !

Bonne nouvelle donc :)