Erweiterungen für die Orion-Cloud-IDE

Orion auf Speed

Tam Hanna
Orion auf Speed

© Shutterstock / sololos

Wer an die Eclipse Foundation denkt, sieht vor seinem inneren Auge einen Anbieter von „Anti-Visual-Studio“. Doch diese Wahrnehmung ist zu simpel: Die Foundation wurde mit dem Ziel gegründet, Open-Source-Entwicklern Infrastruktur zur Verfügung zu stellen. Dass sich daraus eine führende IDE entwickelte, war dem Marktumfeld geschuldet: Es gab zum damaligen Zeitpunkt schlichtweg kein anderes Produkt, das die Bedürfnisse der Open-Source-Welt so effizient abdecken konnte. Da die Entwickler ihr Programm stets selbst benutzten (Dogfooding), bekam es im Laufe der Zeit immer mehr nützliche Funktionen.

Neil Crockfords JavaScript darf auf eine ähnliche Geschichte zurückblicken. Die einst als Werkzeug zur Realisierung „stupider Widget-Animationen“ vorgesehene Sprache erlebte durch Dienste wie Googles GMail eine Renaissance: Das anfangs nur für eingeschränkte Nutzerkreise verfügbare System revolutionierte Webapplikationen dank des damals neuartigen AJAX-Ansatzes.

Hartgesottene Qt-Programmierer hätten nie daran gedacht, dass die diversen Webtechnologien (Stichwort PhoneGap) irgendwann einmal eine Konkurrenz für ihr Lieblingsframework werden würden. Mittlerweile findet sich Digias Produkt in der Rolle des Verfolgers: Play Store und Co. sind voller Applikationen, die mit Webframeworks erstellt werden.

Herkömmliche IDEs sind für dieses neue Anwendungsfeld eher schlecht als recht geeignet: Viele Programmierer arbeiten mit einer Kombination aus Texteditor und im Browser integriertem Debugger. Das Orion-Projekt möchte diesem Problem durch eine radikale Lösung begegnen. Es handelt sich dabei um eine Entwicklungsumgebung, die – im Idealfall – komplett im Browser abläuft und aus Webtechnologien besteht.

Trotz enormer Fortschritte im Bereich der JavaScript-Runtimes ist die Technologie noch lange nicht dazu befähigt, komplett integrierte Entwicklungsumgebungen zu realisieren. Orion setzt hier auf die in Abbildung 1 gezeigte Architektur: Komplexe Funktionen können über diverse Plug-in-Arten realisiert werden. Dienste wie die Verwaltung von Dateien oder das öffentliche Hosting von erstellten Webinhalten erfolgen über einen oder mehrere dezidierte Server. Diese kommunizieren mit dem Editor über eine REST-API.

Abb. 1: Orions Webclient kann auf Plug-ins zurückgreifen (Bildquelle: eclipse.org)

Abb. 1: Orions Webclient kann auf Plug-ins zurückgreifen (Bildquelle: eclipse.org)

Aus technischer Sicht spricht nichts dagegen, die Desktop-IDE per Plug-in mit einem oder mehreren Orion-Diensten zu verknüpfen. Im Moment ist dies nur in eingeschränktem Umfang implementiert: Wer hier Lösungen anbietet, kann kurzfristig erkleckliche Gewinne einfahren. Leider konkurriert er über kurz oder lang mit der Eclipse Foundation – die dabei auftretende Situation erinnert an die von Eric Sink schon 2003 beschriebene Konkurrenzmatrix (Abb. 2).

Abb. 2: Konkurrenten treten in vier Kategorien auf – die Eclipse Foundation dürfte der unangenehmsten Kategorie 3 angehören (Bildquelle: ericsink.com)

Abb. 2: Konkurrenten treten in vier Kategorien auf – die Eclipse Foundation dürfte der unangenehmsten Kategorie 3 angehören (Bildquelle: ericsink.com)

Erweitere mich

Orion-Plug-ins sind JavaScript-Dateien, die in einem nicht sichtbaren iFrame ausgeführt werden. Sie kommunizieren mit dem Editor über von der Eclipse Foundation vorgegebene und als Extension Point bezeichnete Schnittstellen: Es gibt kaum einen Teil des Editors, der nicht auf die eine oder andere Art und Weise erweitert werden könnte.

Wer Plug-ins für die Desktopvariante von Eclipse realisiert hat, muss an dieser Stelle umdenken. Im Web ist es heute unüblich geworden, in einer Webseite mehrere Unterfenster einzubinden. Ein Orion-Plug-in ist keinesfalls mit dem durchschnittlichen Desktop-Plug-in vergleichbar, das einfach ein Fenster mit seinen Optionen in die IDE einschreibt – im Moment ist diese Art der Erweiterung der GUI technisch sogar unmöglich.

Plug-ins leben nach der aus Mafiafilmen bekannten Regel des „Don’t call us“: Sie integrieren sich in das Benutzerinterface des Editors und warten dann auf eingehende Befehle. Im Rahmen der Abarbeitung dieser Kommandos können Sie eigene Widgets auf den Bildschirm bringen – wer mit dem in Orion integrierten UI-Framework nicht auskommt, kann den Benutzer auch in ein neues Tab führen. Nach getaner Arbeit werden die Ergebnisse wieder in den Editor „zurücktransformiert“.

Wir wollen uns Eclipse Orion mit einem kleinen Plug-in nähern, das den gerade ausgewählten Code im Editor mit der Primitivverschlüsselung ROT13 bearbeitet. Diese vergleichsweise simple Aufgabe ist aus didaktischen Gründen ideal, da die Implementierung des „Verschlüsselers“ nicht von der eigentlichen Interfacelogik ablenkt.

Da das Selbsthosten von Orion in Arbeit ausartet, realisieren wir die folgenden Schritte anhand des von der Eclipse Foundation bereitgestellten Diensts OrionHub. Loggen Sie sich unter https://orionhub.org ein – neben einem OrionHub-Konto dürfen Sie sich auch mit Facebook oder Twitter ausweisen. Nach der Anmeldung erscheint die bekannte Orion-IDE, wie in Eclipse Magazin 1.15 beschrieben.

Klicken Sie auf File | New Project | Basic Project, um ein leeres Projekt zu erstellen. In den folgenden Schritten wird der Name ROT13Plugin angenommen: Sie können ihn nach Belieben ändern. Erweitern Sie das Projekt sodann um eine HTML-Datei namens rot13Plugin.htm, die mit dem Inhalt aus Listing 1 ausgestattet wird.

Listing 1

<!DOCTYPE html>
<html>
  <head>
    <meta charset="UTF-8" />
    <title>ROT13Plugin</title>
    <script src="https://orionhub.org/orion/plugin.js"></script>
  </head>
  <body>
    <script>
      var headers = { name: "ROT13Plugin", version: "1.0", description: "Das ist ein Beispielplugin" };
      window.myOrionProvider = new orion.PluginProvider(headers);
      window.myOrionProvider.connect();
    </script>
  </body>
</html>

Das Orion-API wird in zwei Dateien ausgeliefert: Da unser Beispiel im Moment ohne fortgeschrittene Features auskommt, genügt es uns, wenn wir plugin.js laden. Im Body-Tag erfolgt die eigentliche Initialisierung des Plug-ins. PluginProvider nimmt ein JSON-Array entgegen, in dem Informationen über das Plug-in an die IDE weitergereicht werden. Der Aufruf von connect() sorgt sodann dafür, dass der Editor das Plug-in erkennt.

Plug-in laden

Orion-Projekte sind von Haus aus nicht von außen ansprechbar. Wer ein im OrionHub befindliches Projekt mit einem Webbrowser aufrufen und debuggen möchte, muss es in Form einer Site veröffentlichen. Die dafür notwendige Managementansicht lässt sich durch den kleinen grauen Globus auf der linken Seite des Bildschirms aktivieren.

Nach dem Anklicken des Create-Buttons fragt Orion nach dem Namen der neuen Site: In den folgenden Schritten kommt Plugin1Site zum Einsatz. Das Root-Verzeichnis des Deployments lässt sich über den darunter befindlichen Mapping-Editor nach Belieben anpassen – für unsere Bedürfnisse genügt es, wenn Sie ROT13Plugin in den Serverpfad / kopieren (Abb. 3).

Abb. 3: Mappings weisen einzelnen Projekten „Mountpoints“ zu

Abb. 3: Mappings weisen einzelnen Projekten „Mountpoints“ zu

Klicken Sie danach auf den Start-Button, um Orion zur Preisgabe der Zugriffs-URL zu animieren. Sie erscheint normalerweise im Statusfeld – wenn Sie im Moment der einzige Nutzer mit einer Site namens plugin1site sind, so dürfte der URL http://plugin1site.orionhub.org:8000 lauten.

Die Zuweisung des Plug-ins erfolgt im über das Zahnrad aufrufbaren Einstellungsfenster. Nach dem Anklicken des Install-Knopfs erscheint ein kleines Fenster, in dem Sie den URL des Plug-ins eingeben. Falls Sie alles wie im Beispiel festgelegt haben, lautet die einzugebende Adresse http://plugin1site.orionhub.org:8000/rot13Plugin.htm.

Manche Browser – Firefox ist hier ein besonderer „Übeltäter“ – blockieren den Ladeprozess des Plug-ins. Dies äußert sich durch das Anzeigen einer Fehlermeldung nach dem Schema Load timeout for: http://plugin1site.orionhub.org:8000/rot13Plugin.htm, in der Adressleiste erscheint zusätzlich das in Abbildung 4 gezeigte Schild.

Abb. 4: Bei Mozilla ist man gerne „übereifrig“

Abb. 4: Bei Mozilla ist man gerne „übereifrig“

Aus Sicherheitsgründen verhindert Firefox so genannte Mixed Contents. Die Orion-Hauptseite wird per https:// ausgeliefert, während der „Rest“ per http kommen sollte. Klicken Sie das Schild an und wählen Sie die Option Schutz deaktivieren, um das Laden des Plug-ins ordnungsgemäß fortsetzen zu können. In praktischen Deployments wäre es sinnvoller, die Plug-in-Dateien auf einem https-fähigen Server zu deponieren und ebenfalls verschlüsselt auszuliefern.

Als „Lohn“ der Mühen erscheint das Plug-in fortan in der Liste der installierten Erweiterungen. Sie können den Refresh-Button anklicken, um Orion über Änderungen im Plug-in-Code zu informieren: Aufgrund eines vergleichsweise fortgeschrittenen Cachesystems kann es vorkommen, dass eine im Browsercache befindliche ältere Version des Plug-ins zum Einsatz kommt.

Extension Point herbei

Im Moment wird unser Plug-in zwar von Orion erkannt, wirkt sich aber nicht wirklich auf das Verhalten der IDE aus. Dies lässt sich dadurch ändern, dass wir Kontakt zu einem Extension Point aufnehmen.

In am Desktop laufenden Entwicklungsumgebungen würde unser Rot13-Plug-in im Rahmen eines Kontextmenüs auftreten: Der Benutzer bekommt das Werkzeug nur dann zu sehen, wenn er den ausgewählten Code mit der rechten Maustaste anklickt. Heutige Webbrowser bieten ihren Nutzern – normalerweise – ein fertiges Kontextmenü an, das sich nur eingeschränkt überschreiben lässt.

Orion umgeht dieses Problem durch das Anbieten eines Menüs, das von Plug-ins um eigene Kommandos ergänzt wird. Das Andocken setzt – normalerweise – zwei separate Objekte voraus. Programmlogik wird in einem Implementierungsobjekt ausgeliefert, das im Fall unseres Endpoints einen Parameter mit dem aktuell im Editor markierten Text bekommt. Er wandert durch die Verarbeitungsfunktion und wird danach automatisch in den markierten Bereich zurückgeschrieben:

var serviceImpl = {
  run: function(text) {
    return str_rot13(text);
  }
};

Die hier gezeigte Funktion realisiert die „Basisversion“. Sie können diverse weitere Parameter abfragen und retournieren, um so tiefgreifendere Änderungen im Editor vorzunehmen. Weitere Informationen hierzu finden Sie in der Dokumentation des jeweiligen Endpunkts – im Fall von orion.edit.command liegen die Daten hier.

Im Properties-Objekt wird festgelegt, wo die vom Plug-in generierten Steuerelemente angezeigt werden sollen. Wir deklarieren einen Knopf, der zudem über eine Hotkey-Kombination aufrufbar ist:

var serviceProperties = {
  name: "ROT13 anwenden",
  key: ["r", true, true] 
};

Erweiterungspunkte nehmen Dutzende von Parametern entgegen, die in der Dokumentation beschrieben werden. Im Fall unseres Items finden Sie die vollständige Kommandoliste hier – sie können auf Wunsch Symbole oder Tooltips mitliefern, die von der IDE nach Maßgabe des Betriebszustands angezeigt werden.

Damit ist die Deklaration unseres Service fürs Erste fertig. Sie wird im Rahmen der Deklaration des Providers eingeschrieben – ergänzen Sie den im vorigen Abschnitt erstellten Code um die mit registerService() beginnende Zeile:

window.myOrionProvider = new orion.PluginProvider(headers);
window.myOrionProvider.registerService("orion.edit.command", serviceImpl, serviceProperties);
window.myOrionProvider.connect();

Die eigentliche Rot13-Logik übernehmen wir 1:1 von einer bei phpjs.org bereitgestellten Methode, deren Korpus in unserem Fall wie in Listing 2 gezeigt aussieht:

Listing 2

function str_rot13(str) {
  // original by: Jonas Raoni Soares Silva (http://www.jsfromhell.com)
  // improved by: Ates Goral (http://magnetiq.com)
  // improved by: Rafał Kukawski (http://blog.kukawski.pl)
  // bugfixed by: Onno Marsman
  return (str + '')
  .replace(/[a-z]/gi, function(s) {
    return String.fromCharCode(s.charCodeAt(0) + (s.toLowerCase() < 'n' ? 13 : -13));
  });
}

Es handelt sich hierbei um eine sehr kompakte Ersetzungsroutine, die einige fortgeschrittene String-Bearbeitungsfunktionen von JavaScript nutzt. Ihr genauer Aufbau ist für uns uninteressant – viel wichtiger ist, was nach dem Aktualisieren des Plug-in-Codes geschieht.

Öffnen Sie eine Datei Ihrer Wahl im Editor und klicken Sie auf das Tools-Menü. Die von unserem Plug-in beigetragene Menüoption erscheint wie vorgesehen am Bildschirm: Eventuell markierte Codeteile werden ordnungsgemäß mit der Rot13-Funktion verwurstet (Abb. 5).

Abb. 5: Unser Plug-in hat sich in den Editor integriert

Abb. 5: Unser Plug-in hat sich in den Editor integriert

Benutzerinterface herbei

Komplexere Plug-ins benötigen zur Erledigung der ihnen übertragenen Aufgaben oft zusätzlichen Kontext vom Benutzer. Da das Aufpoppen von (modalen) Alerts als lästig empfunden wird, bietet Orion einen aus vier Namespaces bestehenden GUI-Stack an. In der Praxis wird er aufgrund diverser Einschränkungen nur als Quelle von Benutzerevents eingesetzt – es ist bequemer, eine eigene Page mit Logik und Widgets auf den Bildschirm zu schieben.

Als ersten Akt müssen wir unser Projekt um einen Verweis auf die weiter oben erwähnte Deferred-Bibliothek erweitern:

<head>
  . . .
  <script src="https://orionhub.org/orion/Deferred.js"></script>
</head>

Im nächsten Schritt erstellen wir eine zweite Datei namens rot13Dialog.htm. Sie enthält die anzuzeigenden Steuerelemente – für unser Beispiel ist es ausreichend, wenn sie mit zwei Knöpfen (Ja und Nein) und einer Textzeile ausgestattet wird (Listing 3).

Listing 3

<html>
  <head></head>
  <body>
    Wollen Sie rot13 auf die Selektion anwenden?<br>
    <button type="button" onclick="proceed();">Ja!</button> 
    <button type="button" onclick="dont();">Nein!</button> 
  </body>
</html>

Die Auslassung der Inklusion von plugin.js ist kein Druckfehler. Orion zeigt den Dialog als „Teil“ des Editors an, weshalb die diversen Deklarationen und Objekte schon zur Verfügung stehen.

orion.edit.command ruft die run-Methode auf, wenn das Ereignis auftritt. Ihr Corpus kann das Framework darüber informieren, dass die eigentliche Bearbeitung des Befehls in einer separaten Webseite erfolgt. Dazu muss das zurückgegebene JSON-Objekt um einige Parameter erweitert werden (Listing 4).

Listing 4

var serviceImpl = {
  id:"ROT13Plugin.testID",
  run: function(text) {
    return {uriTemplate: "http://plugin1site.orionhub.org:8000/rot13Dialog.htm", width: "600px", height: "400px"};
  }
};

uriTemplate sollte mit Informationen über die ideale Größe des anzuzeigenden Fensters ausgerüstet werden: Neben absoluten Werten in der Einheit px dürfen Sie auch andere CSS-Größeneinheiten verwenden. Bei der Ausführung des Beispiels sollten Sie zudem darauf achten, dass der übergebene URL auf Ihre Site verweist.

Orion lädt den Inhalt des Dialogs in einem Kind-Fenster, das über dem Rest der Seite schwebt. Die Korrelation zwischen eingehenden Ereignissen und auslösenden Dialogen erfolgt über den ID-String, der im Idealfall – wie hier gezeigt – nach dem Schema Pluginname.Funktionsname aufgebaut sein sollte.

Damit können wir uns der Realisierung der mit den beiden Buttons verdrahteten Event Handler zuwenden. Die „Basisversion“ des Codes sieht wie in Listing 5 gezeigt aus.

Listing 5

function proceed()
{
  window.parent.postMessage(JSON.stringify({
    pageService: "orion.page.delegatedUI",
    source: "ROT13Plugin.testID",
    result: "Ersatztext"
    }), "*");
}
function dont()
{
  window.parent.postMessage(JSON.stringify({
    pageService: "orion.page.delegatedUI",
    source: "ROT13Plugin.testID",
    cancelled: true
  }), "*");
}

Beide Routinen nutzen die Funktion window.parent.postMessage, um das Elter(n)-Objekt mit einem JSON-Objekt zu versorgen. Der Aufruf von JSON.stringify sorgt dafür, dass der Parameter in serialisierter Form vorliegt. PageSource muss dabei auf orion.page.delegatedUI stehen, um die im Hintergrund arbeitenden Routinen über die Art der eingehenden Daten zu informieren. Source wird mit der ID korreliert, während die result– und cancelled-Parameter Rückgabewert oder Misserfolg anzeigen.

In der aktuellen Version von Orion scheint es – zumindest zum Zeitpunkt der Drucklegung – einige Bugs zu geben, die die Nutzung der Funktion möglich machen. Dialoge erscheinen entweder gar nicht oder wie in Abbildung 6 gezeigt transparent; die per postMessage abgesendeten Kommandos kommen beim Host nicht an.

Abb. 6: Orion-Dialoge sehen irgendwie „unfertig“ aus

Abb. 6: Orion-Dialoge sehen irgendwie „unfertig“ aus

Eine vom Autor eingereichte Fehlermeldung ist mittlerweile unter https://bugs.eclipse.org/bugs/show_bug.cgi?id=454378 in Bearbeitung – es ist davon auszugehen, dass der Fehler in nicht allzu ferner Zukunft behoben wird.

Object Reference und mehr

Lang laufende Kommandos stellen JavaScript vor ein unangenehmes Problem: Die Sprache kennt keine Threads. Orion begegnet dieser Situation durch so genannte Promises. Wir wollen uns die Verwendung dieser Objekte anhand einer Variante des Rot13-Plug-ins ansehen, das eine künstlich verlangsamte Version des Verschlüsselungsalgorithmus benutzt.

Da die diversen im Editor enthaltenen Methoden synchron ausgeführt werden, besteht die erste Amtshandlung unseres Programms aus der Erstellung und Retournierung eines auch als Promise bezeichneten Deferred-Objekts. Es handelt sich dabei um eine Mischung aus Delegate und Active Object, die die in ihr enthaltenen Aufgaben – einer AsyncTask nicht unähnlich – im „Hintergrund“ erledigt.

Rot13 Langsam unterscheidet sich von seinem „schnell“ arbeitenden Vorgänger durch eine komplett anders aufgebaute ServiceImplementation. Die neue Version des Objekts hat eine wesentlich längere run()Methode, die in Form einer Closure realisiert ist (Listing 6).

Listing 6

var serviceImpl = {
  run: function(text) 
  {
    var deferred = new orion.Deferred();
    var timestamp = new Date().getTime();
    var operationFinished = false;

Wir beginnen mit der Erstellung einer Instanz von Deferred samt einigen Hilfsvariablen. Die auszuführende Payload wird über die JavaScript-Standardfunktion setTimeout zur verzögerten Abarbeitung freigegeben. An ihr ist eigentlich nur der Aufruf von resolve interessant. Die Methode ist dafür verantwortlich, die erfolgreiche Ausführung der Payload anzuzeigen – der als Parameter übergebene Wert wandert an den „Auftraggeber“ zurück (Listing 7).

Listing 7

setTimeout(function () {
  deferred.resolve(str_rot13(text));
  operationFinished = true;
}, 5000);

Lang laufende Operations sollten mit Code ausgestattet werden, der den Benutzer mit Fortschrittsinformationen versorgt. In unserem Fall erfolgt dies über die Methode reportProgress, die die progress-Memberfunktion des Deferred-Objekts aufruft. Diese „Primitivvariante“ blendet die vom Entwickler angegebenen Strings in einem kleinen grünen Pop-up ein, das auf der Oberseite des Editors erscheint (Listing 8).

Listing 8

function reportProgress() 
{
  if (operationFinished)
  return;
  deferred.progress({
    type: "progress",
    timestamp: timestamp
  });

  setTimeout(reportProgress, 1000);
}

Zu guter Letzt folgt ein Aufruf der soeben besprochenen reportProgress-Methode. Danach gibt run() das Promise-Objekt an das System weiter, um es über das Vorhandensein einer asynchron ablaufenden Operation zu informieren (Listing 9).

Listing 9

    reportProgress();
    return deferred.promise;
  }
};

Das Deployment des Plug-ins muss nicht unbedingt in einer neuen Site erfolgen – es ist auch möglich, die für das normale Plug-in verantwortliche Site um einen Unterordner zu erweitern. In diesem Fall entspricht der vom Benutzer aufzurufende URL folgendem Schema: http://plugin1site.orionhub.org:8000/ROT13SlowPlugin/rot13SlowPlugin.htm.

Wenn die Operation einige Minuten in Anspruch nimmt, so sollten Sie sie mit fortgeschrittenem Progress-Reporting ausstatten. Ein so erweiterter Job scheint im Fortschrittsfenster auf, das sich – wie in Abbildung 7 gezeigt – durch Anklicken des Fortschrittssymbols öffnen lässt.

Abb. 7: Lang dauernde Operationen scheinen im Fortschrittsfenster auf (Quelle: eclipse.org)

Abb. 7: Lang dauernde Operationen scheinen im Fortschrittsfenster auf (Quelle: eclipse.org)

Weitere Informationen dazu finden Sie in einem Programmbeispiel, das hier auf Ihre Aufmerksamkeit wartet.

Die Orion-Speisekarte

Unsere Beispiele beschränkten sich aus didaktischen Gründen auf den Extension Point orion.edit.command. Als Plug-in-Entwickler ist man indes nicht auf die Realisierung von Kommandos für den Editor beschränkt – es gibt dutzende von Einsprungpunkten, die die Anpassung des Produktverhaltens ermöglichen.

Da eine detaillierte Besprechung aller im Client-API enthaltenen Features den Rahmen dieses Artikels sprengen würde, beschränkt sich die folgende Tabelle 1 auf die Beschreibung der Rolle der Endpunktgruppe. Weitere Informationen über die spezifischen Unter-Endpoints finden Sie im Developer Guide.

Tabelle 1: Endpunktgruppen im Client-API

Tabelle 1: Endpunktgruppen im Client-API

Einige Dienstleistungen können auch durch das Server-API realisiert werden: Es handelt sich dabei um Aufgaben wie die Synchronisation mit Git oder das Manipulieren von im Dateisystem befindlichen Informationen. Zum Zeitpunkt der Drucklegung stehen die in Tabelle 2 aufgelisteten Funktionsgruppen zu Ihrer Verfügung.

Tabelle 2: Funktionsgruppen im Server-API

Tabelle 2: Funktionsgruppen im Server-API

Von der Eclipse Foundation werden die den jeweiligen Modulen implementierten REST-Kommandos unter https://wiki.eclipse.org/Orion/Server_API dokumentiert. Wer sich mit dem HTTP-Protokoll auskennt, hat mit der Implementierung der Requests keine Probleme. Quereinsteiger sollten sich mit der Theorie des Representational State Transfers und dem HTTP-Protokoll auseinandersetzen, bevor sie sich an die Literatur heranwagen.

Die genauen Signaturen der diversen im Client verfügbaren Methoden werden in einer im JSDoc-Format gehaltenen Referenz vorgestellt. Sie steht unter https://orion.eclipse.org/jsdoc/index.html zum Abruf bereit. Die dort enthaltenen Daten sind in vielen Fällen aktueller als die Informationen des Wikis.

Fazit

Wer heute mit Eclipse arbeitet, wird sehr wahrscheinlich nicht sofort auf Orion umstellen. Debakel wie die überraschende Änderung des Debugging Conduits bei CloudPebble haben dafür gesorgt, dass der durchschnittliche Entwickler dem Gedanken an eine Cloud-IDE mehr als kritisch gegenübersteht.

Das Produkt spielt seine Stärken in einer unerwarteten Situation aus: Es ist geradezu ideal geeignet, um als Basis für „hauseigene Entwicklerdienste“ wie CloudPebble herangezogen zu werden. Orion spart an dieser Stelle Arbeitszeit. Die Realisierung von Editor und Co. entfällt ersatzlos, der (überschaubare) Restaufwand beschränkt sich auf die Anpassung der Toolchain und das Hosting des resultierenden Endprodukts.

Dass es aufgrund des vergleichsweise frühen Entwicklungsstands hier und da zu Fehlern kommt, liegt in der Natur der Sache. Wer auf Nummer sicher gehen möchte, bietet seinen Kunden eine selbstgehostete Instanz von Orion an. Aus der Logik folgt, dass diese nur sehr vorsichtig aktualisiert wird.

Verwandte Themen:

Geschrieben von
Tam Hanna
Tam Hanna
Tam Hanna befasst sich seit der Zeit des Palm IIIc mit der Programmierung und Anwendung von Handcomputern. Er entwickelt Programme für diverse Plattformen, betreibt Onlinenewsdienste zum Thema und steht unter tamhan@tamoggemon.com für Fragen, Trainings und Vorträge gern zur Verfügung.
Kommentare

Hinterlasse einen Kommentar

Hinterlasse den ersten Kommentar!

avatar
4000
  Subscribe  
Benachrichtige mich zu: