Archetype Javascript Framework 0.1

Posté par  (site web personnel) . Modéré par Benoît Sibaud.
Étiquettes :
0
23
oct.
2007
Internet
Archetype est un framework JavaScript (licence MIT). Il ne s’agit pas d’un toolkit qui propose de simplifier le code, c’est un vrai framework, qui modifie clairement la façon de travailler en Javascript, pour le rendre plus efficace, plus lisible et plus modulaire.

Le framework est basé sur les excellentes bibliothèques Prototype et Scriptaculous. Il 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és principalement par JavaScript.

Le projet Archetype a pour but d'offrir aux développeurs web tous les outils pour travailler en JavaScript comme avec les frameworks serveur, mais sans cacher le JavaScript dans une couche serveur (solution à la mode, mais qui s'avère toujours trop simple pour pouvoir réaliser ce que le client désire).

Le serveur continue donc de gérer la sécurité et le métier, mais ne s'occupe plus de gérer une vue ou un contrôleur. Seule une couche de transport telle que DWR permet de communiquer via Ajax avec le client. Le framework offre les services suivants :
  • Gestion intelligente des dépendances, et chargement de l'ensemble des fichiers du projet pour la page demandée : sur les projets avec beaucoup de JavaScript il est courant d'avoir des problèmes de chargement, aussi Archetype prend en charge de manière simple et efficace tous les chargements de fichiers.
  • Améliorations des systèmes objets du JavaScript : héritage, singleton, appel des méthodes parentes, fonctions importées, etc.
  • Un système de logs configurable : JavaScript manque de possibilités pour logguer proprement des informations, et permettre ainsi un débogage aisé de l'application. avec Archetype, plusieurs loggers sont disponibles dans le framework, suivant les besoins, et géré simplement par configuration.
  • Un système de templates HTML (ou tout autre format basé sur du texte) : il est interprété en JavaScript, et permet ainsi de gérer parfaitement un Modèle-Vue-Contrôleur coté client.
  • 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 chargement automatique 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 d'émettre/écouter simplement les événements concernant l'objet.
  • Widgets réutilisables : basés sur les "Component", les "GraphicalComponent" permettent de rassembler simplement un ensemble de fichier css/html/javascript en widget réutilisable de page en page et de projet en projet.
  • Communication évènementielle : grâce à Archetype, il devient simple de communiquer par évènement avec tous les composants, qu'ils se trouvent dans la page elle même ou dans une frame/iframe contenue dans celle-ci.


Archetype offre donc un véritable environnement de travail au développeur, en reprenant les principes des meilleurs outils connus actuellement dans le domaine du développement web côté serveur mais, cette fois, côté client 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é, faciles à faire évoluer et à maintenir.

La version 0.1.0 présente d’ores et déjà le c½ur fonctionnel de ce qui est peut être le premier framework JavaScript prévu dès la base pour gérer une application RIA / Web 2.0 de taille conséquente.

Nous utilisons déjà notre framework dans divers projets mais nous sommes avides de vos retours et de vos commentaires ! Toute aide ou test sur les différents navigateurs sera fortement appréciée.

Nous travaillons actuellement à créer AWiki, un wiki WYSIWYG au fonctionnement proche de TiddlyWiki, basé sur Archetype/TinyMCE/DWR/Spring/ACEGI/Hibernate/MySQL afin de faire un vrai site utilisant Archetype pour accueillir le site du projet, en se basant sur notre framework, aussi toute personne intéressée pour participer à ce projet est aussi la bienvenue.

Vous pouvez nous joindre et nous faire vos retours sur le Google Group (bien sûr, on gardera un oeil ici ;) )

Aller plus loin

  • # Démo ?

    Posté par  (site web personnel) . Évalué à 3.

    J'ai cherché partout mais j'ai pas trouvé de démo. Y'en a une ?
    • [^] # Re: Démo ? Pas encore ...

      Posté par  (Mastodon) . Évalué à 3.

      En parcourant le blog Archetype, je tombe (http://archetypejs.blogspot.com/2007/10/awiki.html) sur :
      Avec une version 0.1 imminente, le besoin d'avoir une démonstration d'Archetype sur un site public est important.
      Toujours pour la même raison, Archetype a de plus en plus besoin de son propre site. Mais le site d'un Framework pour faire des sites a inévitablement une lourde charge car il doit être sa propre démonstration.

      Nous en sommes arrivé à la conclusion suivante : et si, grâce à Archetype, nous faisions un wiki ! En utilisant notre propre moteur de wiki pour notre site, nous remplissons nos deux besoins en une fois !


      Posté le 16/10/2007. Je suppose qu'il faut donc attendre encore un peu ...
      • [^] # Re: Démo ? Pas encore ...

        Posté par  (site web personnel) . Évalué à 1.

        Oui oui !

        Il ya a 2 petites démo :

        - "Hello world" qu'on ouvre avec Start.html

        - Slidy un présentation type "Powerpoint" dans le navigateur faite avec Archetype (on a repris un application disponible sur le site du W3C, d'ou les non hack css pour les navigateur ne supportant pas tout bien à ce niveau là, je corrigerai ça d'ici la 0.1.1 ou la 0.2) qui propose de faire soi même sa première application avec Archetype :)

        Amusez-vous bien :)
        • [^] # Re: Démo ? Pas encore ...

          Posté par  (site web personnel) . Évalué à 1.

          Sinon pour ce qui est d'une vrai démo hébergée, c'est en cour avec la développement de AWiki. On pourrait d'ores et déjà mettre Slidy, mais j'aimerai, pour en faire la démo, lui faire un back avec un BDD et gérer des effets sur les slides avec scriptaculous....

          En ce moment je n'ai pas le net chez moi (déménagement) et seul Swiip peu avancer en dehors du mardi (journée pendant laquelle notre boite nous paye à développer Archetype :D)
          • [^] # Re: Démo ? Pas encore ...

            Posté par  (site web personnel) . Évalué à 1.

            Je suis en train de voir pour héberger le Slidy sur sourceforge, mais de mémoire c'est une vrai plaie pour accèder a l'upload (ajout de la clef ssh, etc.).

            Sinon j'ai d'autre serveur dispo mais pas de nom de domaine potable (on devrait en acheter un quand AWiki sera fini) pour mettre la démo dessu :P
            • [^] # Re: Démo ? Pas encore ...

              Posté par  (site web personnel) . Évalué à 2.

              La démo de Slidy est accessible directement à cette URL:

              http://sd-10490.dedibox.fr/Archetype-0.1.0/WebContent/Slidy.(...)
              • [^] # Re: Démo ? Pas encore ...

                Posté par  (site web personnel) . Évalué à 2.

                Juste un petit truc en passant :
                evite vraiment de mettre des blocs sans accolades (if, for, ...)
                C'est pas pour faire beau, mais quand tu va vouloir compacter ton code, ça ne marchera plus et tu ne saura pas pourquoi...

                (et par contre, pour faire beau, je trouve horrible d'avoir un if avec un bloc et un else sans...)

                (le tout dans la première fonction load)


                Sinon, comment marche le require ? (pour charger des modules, des js, ...)
                Tu as regardé comment marche celui de yahoo [http://developer.yahoo.com/yui/yuiloader] ?
                La description des besoins est assez simple et sympa à mettre en oeuvre.
                • [^] # Re: Démo ? Pas encore ...

                  Posté par  (site web personnel) . Évalué à 1.

                  Oui, le checkstyle nous engueule un peu là dessus, tu as raisons sur les accolades :)

                  Le require représente beaucoup de boulot, car il gère beaucoup de cas différents (synchrone, asynchrone, html, css, js, component) on s'est inspiré un peu de celui de Dojo mais on l'a évidemment fait à notre sauce: le principe est decoder ce qu'on souhaite(html, css, js, etc.) et d'insérer les balises dans le head via les methodes DOM, puis on attend la levé des évènements "load" sur les différentes balises rajoutées

                  Une gestion particulière est faite dans le require pour les composants puisqu'ils ont des dépendances transitives demandant un chargement partiel (puisque defini dans la definition du composant) pour obtenir l'information de ce qui leur est necessaire. Aussi il ne faut appeler le callback qu'à la fin de tous les chargements de dépendance.
                  Pour celà nous utilisons des "LoadJoiner" permettant de savoir quand le chargement d'une liste de fichier est terminée et que l'on peut appeler un callback correspondant.

                  Pour le HTML on ne rajoute pas de balise script, on doit donc se limiter à la XmlHttpRequest et on stocke le résultat dans du JS

                  Pour le CSS on a pas d'évènement load de levé, on le considère donc chargé du moment qu'on le demande (ce qui est relativement vrai).

                  On gère une file de requête à faire pour donner les priorités aux composants(on a eut quelques problème avec, je ne sais pas si c'est comme ça pour la 0.1, c'est plus le domaine de Swiip, en tout cas ça le sera au minimum pour les release suivantes), puisqu'eux même peuvent avoir des dépendances transitive qu'il nous faut connaitre au plus tôt pour avoir toujours une file la plus remplies possible et charger le tout au plus vite.
  • # Du MVC cote client.

    Posté par  . Évalué à -1.

    Du MVC direct sur le client.Voila une idee lumineuse. Que je m'etais jure d'etudier, avant de devenir expert SAP et gagner 10 millions de dollars.
    Ca m'botte...

    PS: SQL en backend d'un tiddlyWiki, je tiens a insister, c'est maaaal !!!!
  • # Surcouche de surcouche

    Posté par  (site web personnel, Mastodon) . Évalué à 0.

    Ça manquait, vraiment, je suis impressionné.
    • [^] # Re: Surcouche de surcouche

      Posté par  (site web personnel) . Évalué à 1.

      C'est horrible les surcouches de surcouches, hein ?

      Genre Hibernate, c'est une horrible surcouche a JDBC lui meme une surcouche au lib d'accès aux BDD ... Mouarf :x
  • # Intégration avec Greasemonkey

    Posté par  . Évalué à 2.

    bonjour,
    ce qui est également pratique dans ces librairies de haut niveau, c'est les manipulations DOM pour faire tout un tas de chose. (par exemple jQuery)

    Est-ce qu'il est facile d'utiliser Archetype dans un script Greasemonkey ? Quelqu'un a un exemple concret ?

    voilà c'est tout, à+
  • # Conteneur Léger ?

    Posté par  . Évalué à 2.

    Est ce qu'il y a un rapport entre la notion de conteneur léger dans Archetype et celle dans le monde java comme l'IoC : http://www.dotnetguru.org/articles/dossiers/ioc/Fowler/IoC.h(...) ?

    Est ce que je peux gérer mes dépendances entre composant avec un fichier xml à la spring et bean ?
    • [^] # Re: Conteneur Léger ?

      Posté par  (site web personnel) . Évalué à 1.

      En effet l'idée vient un peu de là, on pourrait très bien imaginer de l'IoC via les methodBuilder, d'où le vocabulaire utilisé.

      C'est pas encore fait mais la possibilité existe grâce au système des composants... On y pense ;) !

      Sinon le fichier serait sans doute plus du JSON que du XML, ou encore une astuce permettant de faire l'équivalent d'une annotation (les fichiers XML de Conf c'est "hasbeen" par rapport aux annotations dans ces framework ;D ).

      Si ça t'intéresse de nous aider a l'implémenter, ça ne devrait pas être la mort et on accepte volontier ce genre de contribution :)

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.