Le plugin JSEclipse rend le même genre de services. Si on mélangeait les 2, on aurait quasiment le plugin idéal pr éditer du javascript.

J'aime beaucoup Aptana, mais des trucs simples comme l'indication de l'utilisation d'une variable ailleurs dans la page (les petits carré jaune vers la barre de défilement qu'on voit qd on est sur une fonction ou une variable, dans JSeclipse, ou dans l'editeur Java) manque par exemple.

Au début, j'utilisais peu ce genre d'information mais ca évite souvent une recherche dans le code et c'est donc bien pratique sur un code long. JSEclipse possède ce petit plus (qu'on a ususellement dans du coe java d'ailleurs).

Là ou Aptana est fort, c'est sur le "scope" de fichiers pour l'autocomplétion: qd on ouvre un fichier html, il regarde les include javascript et rajoute tout seul dans un "scope" les fichiers pr faire la complétion surles variables contenues. On peut aussi le faire en manuel ce qui est vraiment très pratique.

Là ou dans sa grande force il a une faiblesse, c'est qu'il ne comprend pas "tout". Ainsi, si je ne dis pas de bêtise, il ne fait pas la complétion sur les objets qui ne sont pas créés de manière "naturelle".

Je m'explique : un objetMachin.prototype.methode(param1,param2) permettra d'avoir l'autocomplétion aussi bien sur param1, que param2, ou sur methode. Par contre un objetMachin= Class.create(mapDecrivantLePrototypeContenantLaMethode_methode) ne fonctionnera pas.

Or le 2e cas, avec l'évolution des framework javascript risque d'affluer en grand nombre. Dans notre Framework, Archetyp (cf signature) on a redéfini Class.create pr fonctionner comme dans le 2e cas décrit. On a de la même manière un Component.create (1) et la complétion n'est pas prise en compte (tout comme la Jsdoc du prototype, en tout cas avec JSDoc Toolkit et les options de bases + "-a").

La modification de Class.create dans ce sens est identique dans Prototype 1.6.0rc0 (Archétype est basé sur Prototype 1.5.1, mais l'évolution de Prototype rattrape certaines idées que l'on a implémentées dan Archétype), sachant que c'est le framework javascript le plus utilisé, ca va faire rapidement beaucoup de problèmes.

En même temps c'est normal, comment sait-il que Class.create/Component.create contient une définition d'objet ? 3 solutions: interprêter le code, ou permettre la création de fichier de description de certaines fonctions comme le propose JSEclipse (2), ou encore l'interprêtation de certaines données de la JSDoc de la fonction, cumulé a des conventions (3), ce qui serait ss doute le plus simple !

J'ai parlé JSDoc, je trouve Aptana aussi assez fort dans le domaine, puisque qu'un raccourci permet de construire automatiquement le commenatire JSDoc au dessus de la fonction dans laquelle se trouve le curseur, prérempli des paramètres qu'elle possède.
JSEclipse, lui, se contente de supporter la complétion sur les attributs de la JSDoc, et n'est même pas très à jour dans le domaine d'ailleurs.

Bref tandis que je me résignai à utiliser JSEclipse et abandonner Aptana (4), j'ai trouvé de bon côté a JSEclipse, mais l'éditeur Javascript parfait n'est pas encore là, même si avec Aptana et JSEclipse mélangé, on aurait sans doute un truc vraiment bien pour bosser!

Une chose est sure pour moi, les outils arrivent, on va arrêter de coder du javascript caché dans du code serveur, et on va réèllement codé en javascript pour la vue, le controlleur, et passer par des passerelles de RPC comme DWR pour la communication avec le code métier, pour ne pas avoir a s'en soucier ni à la coder pour chaque appli.
Les éditeurs poussés, comme Aptana ou JSEclipse devraient le permettre sans difficulté pour le programmeur, les navigateurs sont en pleine tendance d'accélération matérielle du graphisme et de patater le javascript, les frameworks permettront de se dégager des soucis de compatibilité (ce qui est déjà fait en grande partie), et faciliteront beaucoup le développement JS, aussi on devrait voir se multiplier dans les prochains mois des appli lourde "web 2.0" dont une bonne partie du développement aura été fait côté javascript, et non caché dans du code coté serveur qui en fait est du javascript (5).

Bon bon bon, amusez-vous bien , et essayez Archetype(6), vous verrez ce que c'est de programmer sympathiquement en JS ;o)

(1) : Les "component" sont des classes améliorées, permettant d'avoir des services ajoutés transversaux(comme l'enregistrement automatique de fonction "onMachin" aux évènements "Machin"), notamment le chargement des dépendances --transitives-- requises à son fonctionnement avant son chargement et permettent de manière aisée de créer des sortes de widgets graphique, séparant vue controleur et model, au lieu de tout mélanger comme des porcs dans du code javascriptohtmlocssoïque, ou pire, "DOMcentrique")

(2) : Je sais que c'est des XML, mais j'ai jamais trouvé ceux de Prototype et j'ai jamais vraiment fouillé, du coup la complétion est assez moyenne dans JSEclipse je trouve, des qu'on utilise des lib de ce type, car il ne connais jamais le scope de ce qui nous intéresse.

(3) : Une annotation "@createObjectByMap param1" par exemple, pour indiquer qu'on va créer un objet a partir de la map "param1" qui se trouve en paramètre

(4) : "sapusaipulibre" c'était pire que pas être libre d'origine ! EN même temps j'avoue ne pas avoir lu la nouvelle license, mais son changement me chigrinait tout de même surtout pour aller vers quelquechose de non redistribuable ou presque ...

(5) : RoR, JSF, Struts, Tapestry5, j'en passe cachent le JS qu'ils utilisent... C'est gentil mais ça ne fait jamais tout ce dont on a besoin, et au final on s'embête plus avec que sans, en utilisant un simple DWR pour communiquer...

(6) : On a un problème de compatibilité avec IE7 pour le moment, depuis qu'on a revu un des fonctionnement du coeur de l'appli, pr le rendre plus astucieux et plus léger(on a supprimé des "eval" et des new Function("") qui nous plaisaient pas du tout par du objet["methode"] simple léger et efficace), c'est pour ça qu'on fait pas encore notre première release (la 0.0.9, on prévoit la 0.1 mi octobre, agrémentée de doc et de petits exemple!) ... Néanmoins le code est Checkoutable sur notre SVN pour faire joujou, n'hésitez pas !
En attendant que je retourne au boulot pour avoir un moyen de débogguer pour IE7, on commence le développement de Awiki, un wiki Wysiwyg fait avec Archetype/TinyMCE/DWR/Spring/Hibernate, basé sur des idées façon tiddlywiki ou xookie, mais avec une BDD derrière, et une vrai gestion de version.