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
- Le blog d'Archetype (20 clics)
- Télécharger Archetype sur Sourceforge (4 clics)
- Le Google Group d'Archetype (6 clics)
- Prototype (3 clics)
- Scriptaculous (2 clics)
# Démo ?
Posté par Aurélien Bompard (site web personnel) . Évalué à 3.
[^] # Re: Démo ? Pas encore ...
Posté par Benoît Bailleux (Mastodon) . Évalué à 3.
Posté le 16/10/2007. Je suppose qu'il faut donc attendre encore un peu ...
[^] # Re: Démo ? Pas encore ...
Posté par Temsa (site web personnel) . Évalué à 1.
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 Temsa (site web personnel) . Évalué à 1.
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 Temsa (site web personnel) . Évalué à 1.
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 Temsa (site web personnel) . Évalué à 2.
http://sd-10490.dedibox.fr/Archetype-0.1.0/WebContent/Slidy.(...)
[^] # Re: Démo ? Pas encore ...
Posté par CrEv (site web personnel) . Évalué à 2.
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 Temsa (site web personnel) . Évalué à 1.
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 Rossel Olivier . Évalué à -1.
Ca m'botte...
PS: SQL en backend d'un tiddlyWiki, je tiens a insister, c'est maaaal !!!!
# Surcouche de surcouche
Posté par LupusMic (site web personnel, Mastodon) . Évalué à 0.
[^] # Re: Surcouche de surcouche
Posté par Temsa (site web personnel) . Évalué à 1.
Genre Hibernate, c'est une horrible surcouche a JDBC lui meme une surcouche au lib d'accès aux BDD ... Mouarf :x
[^] # Re: Surcouche de surcouche
Posté par Snarky . Évalué à 7.
# Intégration avec Greasemonkey
Posté par Guillaume RAMELET . Évalué à 2.
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, à+
[^] # Re: Intégration avec Greasemonkey
Posté par Temsa (site web personnel) . Évalué à 1.
On est très orienté page web, et j'ai a peine commencé a me documenter sur comment faire en sorte que ca marche dans les extension samedi aux JDLL (sur le stand de mozilla).
Si t'as des tuto pr les script grease monkey, par contre, ca m'interesse :)
[^] # Re: Intégration avec Greasemonkey
Posté par Guillaume RAMELET . Évalué à 2.
- la théorie avec l'indispensable Dive into Greasemonkey [http://diveintogreasemonkey.org/]
- la pratique avec un repository de scripts greasemonkey, c'est marrant de se balader ici et de voir comment ont été faits certains scripts [http://userscripts.org/]
Pour l'intégration des librairies dans Greasemonkey, a priori j'ai vu pour l'instant 2 techniques,
- intégrer la librairie dans la page via greasemonkey, et faire une boucle (timeout) en attendant que la librairie soit bien chargée (en testant la présence d'un objet type $ par exemple); c'est expliqué ici [http://terrylurie.com/2006/07/23/how-to-use-javascript-libra(...)] ou là [http://jimbojw.com/wiki/index.php?title=Using_Prototype_and_(...)]
- ou carrément intégrer le code de la librairie dans le script greasemonkey, mais ça demande généralement une modification du code donc pas simple (personnellement c'est ce que j'ai fait avec jQuery); une explication ici [http://groups.google.com/group/jquery-en/browse_thread/threa(...)]
Mon rêve c'est d'avoir directement l'intégration de ces librairies dans Greasemonkey, et tu coches celles que tu veux utiliser dans chaque script ! Ca serait le pied
[^] # Re: Intégration avec Greasemonkey
Posté par Temsa (site web personnel) . Évalué à 1.
[^] # Re: Intégration avec Greasemonkey
Posté par Temsa (site web personnel) . Évalué à 1.
[^] # Re: Intégration avec Greasemonkey
Posté par Guillaume RAMELET . Évalué à 1.
non car au moment où l'event onLoad est lancé, le script Greasemonkey est déjà fini depuis longtemps.
oui car on pourrait très bien attacher les fonctions du scripts greasemonkey à window, et donc rendre ces scripts encore dispos (ce qui est assez crade en fait)
# Conteneur Léger ?
Posté par Alex. . Évalué à 2.
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 Temsa (site web personnel) . Évalué à 1.
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.