Pmtool2
Geschrieben von Olaf Willuhn am
Ich hatte hier ja schon einige Mal erwähnt, daß ich Pmtool eventuell mit Java weiterentwickeln würde. Hier im Büro verwende ich nun eine erste Version davon. Es ist ebenfalls als Jameica-Plugin realisiert, eine Taskbar zur Schnellerfassung von Stunden gibt es auch wieder - nur halt nicht als HTML-Seite sondern als kleines SWT-Fenster. Bei der Gelegenheit habe ich auch das Datenbankschema etwas aufgeräumt. Und die erzeugten XML-Rechnungen werden nun nicht mehr in einem XLST-tauglichen Browser gerendert sondern direkt von Pmtool mittels Xalan. Es werden also direkt HTML-Rechnungen erzeugt, die auch in einem Browser angezeigt werden können, der kein XSLT versteht. Pmtool2 ist nun also keine Web-basierte Software mehr sondern quasi eine Richclient-Applikation. Eine offizielle Webseite gibt es noch nicht, wird aber sicher irgendwann folgen. Falls ihr jetzt schon einen Snapshot haben wollt, dann sagt Bescheid und ich stell die bisherige Arbeit als Download zur Verfügung.
Trackbacks
Trackback-URL für diesen EintragDieser Link ist nicht aktiv. Er enthält die Trackback-URI zu diesem Eintrag. Sie können diese URI benutzen, um Ping- und Trackbacks von Ihrem eigenen Blog zu diesem Eintrag zu schicken. Um den Link zu kopieren, klicken Sie ihn mit der rechten Maustaste an und wählen "Verknüpfung kopieren" im Internet Explorer oder "Linkadresse kopieren" in Mozilla/Firefox.
Keine Trackbacks
Die Kommentarfunktion wurde vom Besitzer dieses Blogs in diesem Eintrag deaktiviert.
Kommentare
Ansicht der Kommentare: Linear | VerschachteltAlex Bär am :
wollte nur kurz anmerken, dass ich mit Xalan nie so richtig zufrieden war. Aus praktischer Erfahrung kann ich dagegen Saxon empfehlen. Besser dokumentiert, schneller, viel näher am Standard, kann XSL-T 2 (was ein sehr großer Vorteil ist, da hier bspw. endlich mehrere Ausgabedokumente mit einem Befehl erzeugt werden können, um nur einen Pluspunkt zu nennen).
Der Wechsel von Xalan zu Saxon ist denkbar einfach: Sofern man keine Xalan-Spezialitäten im Programm benutzt hat.
Damit kein Missverständnis aufkommt: Ich meine die Open-Source-Version von Saxon, die kommerzielle wäre für Vielnutzer dank XSL-T-Debugger etc. aber natürlich auch interessant. Und ich stehe in keinerlei Geschäftsverbindung mit der Firma Saxonica, bekomme keine "Zuwendungen" von dort, und werde nicht gesponsort dafür, dass ich Saxon empfehle. Ich finde das Teil einfach nur aus praktischer Erfahrung gut.
Grüße
Alex
Olaf am :
Alex Bär am :
Das bringt mich zu Jakarta. Also.... Das ist eine Ecke mit viel guter, teilweise sogar sehr guter Software von sehr talentierten, aber leider wenig hilfsbereiten Entwicklern...
Beispiel: Man stellt fest, dass eine server.xml aus einer früheren, keineswegs sehr alten Version von Tomcat mit einer neuen Version einfach nicht funktioniert, und fragt auf der Mailing-Liste, wie sich die alten Einstellungen in die neue Konfigurationsdatei übernehmen ließen. Aus Versehen habe ich noch den Fehler gemacht, anzuregen, ein XML-Schema für die server.xml zu definieren, denn dann könnte man mit einem Werkzeug wie MapForce das alte und das neue Schema für eine halb-automatische Transformation der alten Konfigurationsdatei in das neue Format nutzen.
Antwort: "Wir Entwickler haben besseres zu tun als zu dokumentieren oder XML-Schemata zu definieren. Außerdem geht das bei der server.xml gar nicht (zu komplex, zu häufigen Änderungen unterworfen)". Da habe ich mich dann gefragt, warum die Konfigurationsdatei dann überhaupt ein XML-Dokument ist, aber solche Fragen sind natürlich Ketzerei. ;-)
Leider ist somti jedes Upgrade ein Riesen-Akt, weil nirgends beschrieben ist, welche früher mal verfügbaren Optionen nun wie geändert wurden. In einer industriellen Umgebung ist so etwas schlicht unakzeptabel.
Ich vermute allerdings, dass hier ganz klar kommerzielle Interessen dahinter stecken: Wer würde noch Websphere (oder andere) kaufen, wenn das Open Source Produkt jetzt auch noch mit Kontinuität und Upgrade-Sicherheit punkten würde... (Und im Jakarta-Umfeld sind viele "Blaue" zu finden).
Zusammengefasst: Xalan habe ich aus technischen Gründen ersetzt, dass ich Jetty lieber mag als Tomcat liegt dagegen weniger an der sauberen Architektur, den geringeren Hardware-Anforderungen, der besseren Webserver-Komponente, der vollständigeren Doku oder der Möglichkeit der "Einbettung", sondern daran, dass man in der Community freundlicher miteinander umgeht.
Das sind aber, wie gesagt, ganz persönliche Erfahrungen. Harte, technische Fakten waren nur bei Xalan ausschlaggebend für meine Abwendung von Jakarta.
Übrigens finde ich, dass sich hier einer der allergrößten Vorzüge von Java zeigt, nämlich dass es eben nicht in erster Linie eine Programmiersprache oder eine technische Plattform darstellt, sondern eine Sammlung von Spezifikationen; und Werkzeuge, die die Spezifikation einhalten, kann man gegeneinander austauschen. Schön, dass man die Wahl hat!
Weil wir nun schon bei so grundlegenden technischen Details sind: Warum eigentlich SWT...? Wegen Eclipse? Ist SWT wirklich einfacher zu benutzen als Swing?
Grüße
Alex
Olaf am :
> teilweise sogar sehr guter Software von sehr talentierten, aber leider
> wenig hilfsbereiten Entwicklern...
Zu Jakarta hab ich so eine Art Hass-Liebe. Wie in nem Baumarkt findet
man bei denen fuer so ziemlich alles eine Loesung. Nur zieht sie
entweder einen Rattenschwanz weiterer abhaengiger Jars mit sich.
Oder aber die Ansprueche an ein generisches Framework waren den
Entwicklern so hoch, dass sie ein abstraktes Konstrukt erzeugt
haben, das zu 90% aus unverstaendlichem XML gepaart mit Maven
besteht und am Ende zu nichts weiter taugt, als sich selbst zu
transformieren, um aus Maven-Dateien, Ant-Scripts zu erzeugen,
die Stubs von Java-Klassen erzeugen, um damit XML-Beans zu generieren,
die dann Maven-Projekte erzeugen.
Oder aber das Jakarta-Projekt ist unter der Haube eigentlich
so trivial, dass man es auch gleich selbst schreiben kann.
In den jakarta-commons gibt es eine Reihe von Util-Klassen,
die zu nichts weiter nuetze sind, als sql.Resultset exceptionfrei
zu schliessen oder InputStreams in Strings schreiben.
Aber hin und wieder findet man eine Perle.
Naja, und Saxon roch mir irgendwie kommerziell ;)
> Beispiel: Man stellt fest, dass eine server.xml aus einer früheren,
> keineswegs sehr alten Version von Tomcat mit einer neuen Version einfach
> nicht funktioniert, und fragt auf der Mailing-Liste, wie sich die alten
> Einstellungen in die neue Konfigurationsdatei übernehmen ließen....
ROFL
Wie ich diese server.xml hasse! Die Struktur aendert sich permanent.
Der Klassiker: Port 8080 aendern. Lief bei mir immer auf ein grep
ueber alle .properties und .xml Dateien hinaus.
Das ganze dann noch mit mod_jk an einen Apache koppeln und die
grauen Haare kommen schneller als Catalina loggt ;)
Gluecklicherweise hab ich in letzter Zeit nur noch wenig mit
JSP/Servlets zu tun und kann mich auf Plain-Java und Schnittstellen-
Programmierung konzentrieren.
> Weil wir nun schon bei so grundlegenden technischen Details sind: Warum
> eigentlich SWT...? Wegen Eclipse? Ist SWT wirklich einfacher zu benutzen
> als Swing?
Eigentlich war es Zufall. Wir mussten mal einen Prototypen fuer eine
Paketversand-Software bauen, die der existierenden moeglichst aehnlich
sein sollte. Also nahmen wir SWT, da es die OS-Widgets verwendet. Und
da ich vorher noch nie grossartig was mit Swing gemacht hatte, fing
ich dort erst an, mich naeher mit GUI-Programmierung zu beschaeftigen.
Und wenn man sich einmal in die API eingearbeitet hat, bleibt man
gern dabei.
Mir gefaellt, dass es (Achtung, Standard-Anti-Swing-Argument) nicht
wie Java (baeh, Metal-Look) aussieht und trotzdem "nah am Metal" ist.
Sprich: Zwischen den SWT-Methoden und den JNI-Aufrufen zum nativen Code
befindet sich nicht viel. Der Nachteil ist allerdings: Die Umfang
der moeglichen GUI-Elemente ist auf den kleinsten gemeinsamen Nenner
aller unterstuetzten Plattformen beschraenkt. In Sachen LayoutManager
nimmt es sich zu Swing jedoch nicht viel: Wenn man nicht irgend
eine Art GUI-Framework verwendet, entsteht ellenlanger Spaghetti-Code.
Das Standard-Anit-SWT-Argument, dass man allokierte Ressourcen immer
mittels dispose() manuell freigeben muss und das ja den Java-Paradigmen
(GC) widerspricht, kann man aber leicht mit einem Miniframework umgehen,
welches ausgeblendete GUI-Elemente automatisch rekursiv disposed.
Gruss
Olaf
Alex Bär am :
Zu Jakarta: Tja, da weißt du ja dann, was ich meine...
Zu Saxon: Es gibt eine freie und eine kommerzielle Version. Wie üblich. Es gibt Tomcat und Websphere (ok, der macht etwas mehr, aber in Bezug auf Servlets und JSP ist's ein Tomcat). Aber wenn Xalan nun mal schon eingebunden ist, und tut, was er soll, und wie, dann gibt es keinen Grund zu wechseln.
Viel Spaß weiterhin!
Alex
Matthias Fraaß am :
> Wie in nem Baumarkt findet man bei denen fuer so ziemlich alles eine
> Loesung. Nur zieht sie entweder einen Rattenschwanz weiterer abhaengiger Jars mit sich.
Auch "commons-cancer" genannt =).
Zur server.xml / Jakarta-Problematik: Ich finde daß die Upgrade-Hölle in kommerziellen Produkten genauso existiert. Und wenn's nicht server.xml ist dann halt spätestens bei der ejb-jar.xml und deren proprietärer Brüder.
Jakarte täte ein eiserner Besen und eine Autorität gut, die den Entwicklern beibringt, welche Auswirkungen manche ihrer Entscheidungen auf die Nutzer hat.