Lotus Notes / Domino Sonstiges > Java und .NET mit Notes/Domino
eclipse plug-in Entwicklung: Kommt man da rein?
flaite:
Macht nach wie vor Spaß.
Mein Plug-in klinkt sich in einen automatisierten Entwicklungsprozess von einer bestimmten, klar definierten Form von Versicherungsanwendungen ein.
In diesem Entwicklungsprozess sollen die Entwickler aus Excel generierte xml Dateien nach Eclipse importieren.
In Eclipse können sie die xml Dateien verändern.
In Eclipse können sie ausserdem einen bestimmten Typ von Java Klassen (Prozess Skripte) schreiben.
All dieser Code wird in einer Notes-Datenbank gehalten.
In meinem Plugin können die nun per rechter Maustaste auf das Eclipse-Projekt klicken und per Aktion in der dropDown Liste anfordern, dass die Daten in Eclipse mit den Daten in den Notes-Datenbanken repliziert werden.
Dafür erhalten sie den folgenden Report.
Per Klick auf den Details Button erhalten sie ausführlichere Informationen.
Mit Eclipse kann man solch eine solche Reportmaske mit 80 Zeilen erzeugen. Und dabei hab ich das noch sehr flexibel erzeugt. Das ist allenfalls sehr lose verdrahtet und der interessierte Anwendungsentwickler besitzt sehr viel Flexibilität.
ECLIPSE ROCKS O0
Gruß Axel
flaite:
And now the weird part:
46 Zeilen xml, um eine einfache hide when Funktionalität zu implementieren:
Das ist aus dem plug-in.xml von org.codehaus.xfire.eclipse.ui_1.0.0.xfire112.jar
--- Code: ---<extension
point="org.eclipse.ui.popupMenus">
<objectContribution
adaptable="true"
id="org.codehaus.xfire.eclipse.ui.xfireProject"
objectClass="org.eclipse.core.resources.IProject">
<visibility>
<and>
<objectState
name="nature"
value="org.eclipse.jdt.core.javanature"/>
<objectState
name="nature"
value="org.codehaus.xfire.eclipse.xfirenature"/>
</and>
</visibility>
<action
class="org.codehaus.xfire.eclipse.ui.popup.actions.AddRemoveNature"
enablesFor="+"
icon="icons/x16.png"
id="org.codehaus.xfire.eclipse.ui.actions.removeNature"
label="%popup.menu.nature.remove"/>
</objectContribution>
<objectContribution
adaptable="true"
id="org.codehaus.xfire.eclipse.ui.noXfireProject"
objectClass="org.eclipse.core.resources.IProject">
<visibility>
<and>
<objectState
name="nature"
value="org.eclipse.jdt.core.javanature"/>
<not>
<objectState
name="nature"
value="org.codehaus.xfire.eclipse.xfirenature"/>
</not>
</and>
</visibility>
<action
class="org.codehaus.xfire.eclipse.ui.popup.actions.AddRemoveNature"
enablesFor="+"
icon="icons/x16.png"
id="org.codehaus.xfire.eclipse.ui.actions.addNature"
label="%popup.menu.nature.add"/>
</objectContribution>
</extension>
--- Ende Code ---
Tja. Und ich hab jetzt 4 Stunden rumprobiert und bin nicht drauf gekommen. Die erfolgreichen, fiebrigen und glücklichen Überstunden von gestern abend sind somit buchhalterisch wieder weg.
Wie kann man nur so dumm sein, darauf nicht zu kommen.
Schliesslich gibts neben dem <visibility> nur <filter> und <selection> für Funktionalität, die ich erstmal unter dem zugegeben etwas grobkörnigen Begriff hide-when subsumiere. ;D
Ende gut alles gut. Und xml ist wirklich der absolute Burner zur Deklaration von Boolescher Logik:
--- Code: ---
<and>
<objectState
name="nature"
value="org.eclipse.jdt.core.javanature"/>
<not>
<objectState
name="nature"
value="org.codehaus.xfire.eclipse.xfirenature"/>
</not>
</and>
</visibility>
--- Ende Code ---
Wenn das Projekt eine java Nature und eine xfirenatue hat, dann zeige den Kontextmenü-Eintrag.
Ich kann das jetzt gut auf meinen eigenen Bedarf anpassen.
Am Wochenende werd ich ein kleines Programm schreiben, dass mir jederzeit sämtliche plugin.xml von meiner Festplatte scanned und in ein großes File packt :-) Die Dinger beginnen für mich eine Bedeutung zu gewinnen wie Gold-Nuggets in Klondike für Dagobert Duck.
Ein Vorteil von openSource ist wirklich, dass jederzeit geschaut werden kann was andere bereits gemacht haben.
Gruß Axel
flaite:
Eclipse gerät nun mehr in den Fokus und ich versuche (nach Eclipse-Art) in die entsprechenden Textstellen meine eigenen Punkte einzupluggen.
http://www.itbusinessnet.com/articles/viewarticle.jsp?id=61731
--- Zitat ---Notes developers will, in contrast, notice quite a few changes.
--- Ende Zitat ---
Die Entwickler werden am meisten von den Änderungen spüren.
--- Zitat ---"If you want functionality, you can just add it," he said, by writing a plug-in so that Eclipse will understand and debug... well, COBOL, if you felt like it.
--- Ende Zitat ---
... das sind natürlich starke Aussagen. Eclipse besitzt natürlich ein sehr effektives plug-in Konzept. Aber um damit umgehen zu können, gibts schon sowas wie eine Lernkurve.
Du brauchst Funktionalität? Kleines Hütchenspiel? Kein Problem. Du schreibst einfach ein plug-in in Cobol, Dänisch oder Kisuaheli und zack... es läuft.
--- Zitat ---To create plug-ins -- the Eclipse contribution mechanism -- you typically write the code in the Eclipse PDE or in Rational RAD, and package it into what Eclipse calls a "feature" (which just means a set of plug-ins).
--- Ende Zitat ---
Das ist imho leicht irreführend. Es gibt einfach unterschiedliche Möglichkeiten plug-ins zu verteilen. Das besondere ist: Man muß sie nicht in einer zentralen Registry anmelden. Eclipse findet sie selber.
Jede Eclipse-Installation hat ein plugin Unterverzeichnis.
Da liegen die "plugins selbst" drin.
Das einzelne "plugin selbst" ist einfach erstmal ein Ordner mit bestimmten Dateien drin (immer ein plugin.xml und seit neuerem auch ein manifest.mf in META.INF).
Seit neueren kann diese Dateistruktur auch als .jar-Datei (kann von Winzip geöffnet werden, .jar ist von der Dateistruktur .zip) gepackt sein.
Die plugins können auf unterschiedliche Weise auf die Clients verteilt (in Java heisst das "deployed") werden.
Und jetzt erst kommen features im Spiel. Über features kann man einen update Server schaffen, von dem Clients die neuesten plug-ins automatisch herunterladen. Schöne Sache.
Zur Entwicklung
Plug-ins bestehen aus diesen esoterischen plugin.xml und Manifest.mf Dateien sowie einer Reihe von - zumeist - Java Dateien.
Das PDE (Plug-in Development Environment) ist eine besondere Eclipse Perspektive, die einen bei der Entwicklung von plug-ins unterstützt.
Also in Notes-Sprache: PDE ist ein Designer für Eclipse Clients.
Und Perspektive in Notes-Sprache? Eine bestimmte Zusammenstellung von Ansichten und Masken.
Und wie bekomme ich diesen PDE? Der ist bei jeder normalen Eclipse Installation dabei.
Um plug-ins schreiben zu können muß man nicht nur Java können, sondern eben auch die ganze plug-in API mit Lebenszyklen der Objekte, etc. verstehen. Das geht aber (zumindest im meinen Fall). Vor allem gibt es eine Menge Beispiele, von denen ich abschreibe.
ABER: Das heisst nicht, dass man einen Rooky mit ein paar Java-kenntnissen da ranlassen sollte. Zumindest nicht alleine.
--- Zitat ---You can write the code once for multiple products, so that the same plug-in (assuming I understood Eisen correctly) will work with both Hannover and Sametime.
--- Ende Zitat ---
Irgendwie ist das so. Falls man für Hannover und Sametime die gleiche Funktionalität benötigt.
Eclipse-Plugin Entwicklung ist erstmal GUI Entwicklung. Man erweitert den Client. Das könnte man auch mit Java-Swing machen. Eclipse bewirkt aber, dass man schon eine Menge Sachen, die in Eclipse vorhanden sind, verwenden kann. Ausserdem ist man in einem ziemlich coolen und gut funktionierenenden plug-in Konzept. D.h. der eigene Code bindet sich nahtlos in bestimmte vorhandene Extension points ein. Das macht die Entwicklung zwar kompakter (im Sinne von echt wenig Code zu schreiben) aber eben auch abstrakter und komplexer. Das hab ich erwartet und das denke ich zu bekommen, seit 5 Wochen intensiv.
--- Zitat ---A lot of Hannover's "look," says Eisen, is defined in CSS, and other parts of the product rely heavily on XML.
--- Ende Zitat ---
Beides geht in die selbe Richtung wie im vorherigen Abschnitt angesprochen.
Das macht die Entwicklung zwar kompakter (im Sinne von echt wenig Code zu schreiben) aber eben auch abstrakter und komplexer.
--- Zitat ---At their simplest, composite applications are a bunch of components that "bring the portal integration model to the rich client," said Eisen. Hannover supports loosely coupled component interactions, and uses a common definition for both the Web and rich clients. One advantage to composite apps is that they can help you access Domino data from Java. You can get indirect access to the data through composite applications and a property broker -- among several other methods.
--- Ende Zitat ---
Esther Schindler: loosely coupled component interactions
Axel Janßen: Oh. Indeed. Lovely.
E.S.: uses a common definition for both the Web and rich clients.
A.J.: das ist ein bischen konkreter. Strebt eine gemeinsame Entwicklung für Notes und Web Client an. Wobei... Auch mit Eclipse unter der Haube sind Client - Server Notes Anwendungen etwas anderes wie Webanwendung. Von der Kommunikation her. Auch in Zeiten von Web2.0. Es verwundert mich hier nicht, dass bei Leuten wie vowe Assoziationen mit dem gescheiterten Notes-Web Ideen des Jahres 2000 auftauchen. Zumindest interpretiere ich so einige Aussagen. Nur ist das imho nicht ganz richtig.
Vergangenheit:Ich war übrigens 1999 nach 5 Minuten gegen Applets in Notes. Bei der Präsentation eines Notes 5 Alpha Releases. Und die Trainer fanden es toll. Und ich kämpfte mit JavaScript/DHTML/eine Menge Notes-Tricks Webinterfaces, inspieriert von Rose Kellehers Buch. Ich konnte (und mochte) damals Java. Hab trotzdem die Applets nach 5 Minuten gehasst. Eclipse ist anders.
E.S.: One advantage to composite apps is that they can help you access Domino data from Java.
A.J.: Na. Klasse. ERst stark anfangen von wegen loosely coupled component interactions und wenns dann konkret wird... Boah. Wir können aus Java auf Domino Objekte zugreifen. Das gibt ja ganz neue Perspektiven :-) . Gut wir können das natürlich schon seit ewigen Zeiten und mit der Zeit ist man auch mit den gotchas klargekommen.
E.S.: you can get indirect access to the data through composite applications and a property broker -- among several other methods.
A.J.: Weiss nicht, was sie meint.
--- Zitat ---You don't have to drop everything and become an Eclipse expert. (Not that it would hurt.) You'll still use Domino Designer for Notes application development; that isn't Eclipse-based. YET, stressed Eisen.
--- Ende Zitat ---
Aus meiner Sicht gilt hier das gleiche wie Java. Der lila Eclipse Elephant ist einfach zu groß als dass man ihn an einem Wochenende verspeisen könnte. Genau wie den Weißen Java Wal.
--- Zitat ---The Domino Designer will now support DB2 (that was "limited availability" in ND7), and your apps can consume Web services.
--- Ende Zitat ---
Natürlich braucht man in der realen Welt bei der DB2 gestützten Entwicklung auch Leute, die was von RDBMS und DB2 verstehen. Die geforderte Tiefe des Verständnisses richtet sich nach der Komplexität der Aufgabe. Das gleiche gilt natürlich für Webservices/XML und Service Oriented Architecture (SOA).
--- Zitat ---Composite apps will add a few new wrinkles for Notes administrators, most of which are positive. Admins should be more than pleased by new functionality related to user policy management (particularly related to other new features, such as spam filters and message recall), and more control over the way Notes applications are kept up to date.
--- Ende Zitat ---
Hmm. Composite Apps. Weiss jetzt nicht was dieses Konzept jetzt genau sagen will. Hört sich wie ein Marketing Konzept an. Nix gegen Marketing. Aber mein Job besteht zum großen Teil darin, dass ich die technische Seite verstehe und da hab ich die Erfahrung gemacht, dass Marketing Begriffe eine Fauna an Bodendeckern liefern, die die Sichtweise auf die nackten technischen Tatsachen eher verstellen. Aber nein. Ich hab damit kein Problem.
--- Zitat ---They expect to add more composite application functionality, such as a Click-2-Action UI and templated Notes components, and eventually to have full support of Java views for more than PIM. Though, Eisen said wryly, "You're welcome to try now." Later enhancements, he says, should include APIs for productivity editors and deeper RSS/ATOM integration.
--- Ende Zitat ---
Schaun mer mal. Besser "Time is on my side" von den Stones als "I am still waiting" von Donna Summer. Also rolle ich meine eigenen plug-ins. Wär schlimm, wenn ich für Click-2-Action IBM bräuchte. Was heisst das. Ich klicke irgendwo und es startet eine Aktion ? Wahnsinn. Das da keiner früher drauf gekommen ist.
Bernward Vesper
PS.
Das war ein kleiner Scherz. Ich möchte nur dieses kleine Buch empfehlen. Wirklich ein gutes Buch. Zumindest für mich.
http://www.amazon.de/Ensslin-Baader-Urszenen-deutschen-Terrorismus/dp/3596156912/sr=8-2/qid=1157392571/ref=pd_ka_2/303-2025857-5155415?ie=UTF8&s=gateway
flaite:
Gestern habe ich mir nun ein weiteres Buch gekauft:
Berhold Daum, Rich Client Entwicklung mit eclipse 3.1
http://www.amazon.de/Rich-Client-Entwicklung-mit-Eclipse-3-1/dp/3898643530/ref=pd_bxgy_w_text_b/303-2025857-5155415?ie=UTF8
Berthold Daum hat vorher bereits Bücher über Eclipse Entwicklung herausgegeben. Sie sind z.T. in Englisch und wirklich interessant.
Ralf hat dieses Buch gekauft und bei Amazon.de mit 2 Sternen bewertet (zu viele Themen, oberflächlich). Ich stimme dem teilweise zu. Auch für RCP Entwicklung sind die von mir oben angesprochenen plug-in Bücher die besseren Tutorials. Daums Buch beschreibt da eher RichClient Application mässige Erweiterungen. Das aber hochinteressant.
In den mehr Tutorial-Artigen Büchern gibts den lineareren Aufbau:
-> plugin-Architektur -> einzelnes plug-in grober Aufbau -> swt-api -> jface-Api -> Views -> Editoren -> Aktionen -> Wizzards, Dialogs -> Perspektives -> Preference & Property Pages -> IDE spezifisches -> Java Development Tools spezifisches -> Help -> Internationalization -> Deployment & Packaging.
Bei Daum ist es weniger linear. Es scheint mir sogar auf die plug-in Bücher aufzusetzen.
Eclipse RCP gibts ja erst seit 3.1 in dieser Form; für Leute, die bereits Erfahrungen mit eclipse-plug-in Entwicklung allgemein haben.
Physisch von den Plug-ins hergesehen ist Eclipse RCP erstmal eine Teilmenge von Eclipse. Die IDE-spezifischen Teile werden da nicht benötigt. Daum schlägt nun mehrere Lösungen für verschiedene Rich Client mässigen Erweiterungen vor:
- Datenspeicherung in xml und RDBMS
- Synchronisation der Daten zwischen Clients und Server
- Erweiterungen basierend auf dem Graphical Editing Framework
- OpenOffice einbinden
- PDF Generierung
Auf die Verteilung der Clients und dem update Mechanismus der Anwendungen wird sehr umfassend eigegangen.
Nach ein paar Leseproben habe ich den Eindruck, dass das Buch sehr gut und differenziert geschrieben ist, sich aber an den erfahreneren Eclipse plug-in Entwickler richtet.
Gruß Axel
Mark³:
ich habe das Buch von Daum als Einstieg in die Entwicklung mit Eclipse genutzt, leider habe ich es nur halb durchgearbeitet bisher. Es waren ganz gute Aspekte drin, aber oft war es mir zu speziell und an sein Beispiel gebunden, welches ich nicht einmal komplett importieren konnte da da viele Abhängigkeiten zu anderen Sachen drin waren und auf der Webseite die Update-Site nicht funktionierte (letztes Jahr Weihnachten habe ich das gekauft).
Zumindest konnte ich auch mit Hilfe des Buches meine ersten kleinen RCPs erstellen. Bei der Problematik mit Fehlern bei der Projekterstellung und manuell zu bearbeitenden Manifest-Dateien etc konnte das Buch nicht helfen, da muss man wohl grundlegendere Sachen nehmen.
Navigation
[0] Themen-Index
[#] Nächste Seite
[*] Vorherige Sete
Zur normalen Ansicht wechseln