Le 5 septembre dernier, l'équipe d'Aptana annonçait un changement de licence, passant d'Eclipse Public License (EPL) à L'Aptana Public License (APL). Ce choix était motivé pour garder un certain contrôle des travaux dérivés : l'EPL est similaire aux BSD, elle ne requiert pas la redistribution des modifications, même commercialisées sous forme propriétaire. On peut supposer que la principale motivation était de protéger la marque ou d'éviter une version propriétaire éditée par un tiers.
Beaucoup ont accueilli cette nouvelle avec consternation - ce projet étant très prometteur - mais l'APL pose des contraintes fortes pour la redistribution, notamment au sein des distributions (dans une moindre mesure, comme la politique Mozilla pour Firefox, de part la protection de la marque, par exemple).
Or aujourd'hui, Paul Colton annonce que désormais Aptana sera distribué sous deux licences, à choisir selon les besoins entre l'APL et la GPL. Le résultat est que les intérêts de tous sont préservés, la liberté de redistribution pour les libristes, et - pour peu que la qualité du code et les orientations du projet restent populaires - le contrôle du projet pour l'équipe d'Aptana.
(Commentaires et description plus personnelle du projet dans le corps de l'article) J'utilise Aptana depuis RadRails, son ancien nom, où il était alors encore un éditeur Ruby On Rails. En écrivant RadRails, l'équipe s'est vite rendu compte qu'il y avait besoin de faciliter l'édition de code JavaScript et HTML, même entrelacé dans du code Ruby.
Les besoins ont été remis a plat et, maintenant, Aptana est un éditeur fantastique pour l'édition de code HTML, CSS, JavaScript et, à terme, PHP, RoR et autres, les parseurs étant capables d'extraire et de construire une structure de code même lorsque tout est mélangé, ce qui fait que par exemple, vous pouvez avoir une complétion de code sur l'attribut class d'un élément HTML qui proposera une liste des classes déclarées dans le code CSS, et ce même dans les feuilles de style externes. Les attributs onclick vont avoir la complétion de code contenant les déclarations du fichier en cours. Il va aussi, par exemple, télécharger tout seul un lien vers un JavaScript externe pour permettre la complétion de code. Et donc évidement la complétion de code entre diverses balises script vous proposera tous les choix valides (cela marche par contre, garanti testé).
Ce qui est aussi formidable c'est que cette logique est appliquée partout, et des automatismes bien pensés vous attendent a tous les recoins. Le tout chapeauté par tous les services qu'Eclipse sait déjà rendre. Le revers de la médaille est que ce projet est assez jeune et des petits bugs vous attendent à tous les recoins (aussi). Mais pour celui qui peut s'accomoder de ces bugs (en général petits), c'est très agréable.
Donc, merci Aptana et longue vie à ce projet !
Aller plus loin
- Aptana IDE opte pour une licence propriétaire (18 clics)
- Aptana IDE Goes Dual License: APL & GPL (4 clics)
- Aptana - Site principal (6 clics)
- Présentation d'Aptana sur Wikipedia (5 clics)
# A noter
Posté par Temsa (site web personnel) . Évalué à 3.
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.
[^] # Re: A noter
Posté par Julien Wajsberg . Évalué à 1.
Et je ne rentrerai pas dans le troll de comparaison des frameworks JS :) (mais jQuery, c'est bon, mangez-en !)
[^] # Re: A noter
Posté par Jean-Philippe (site web personnel) . Évalué à 1.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.