Ok. Back to 2012. Eine Ist-Aufnahme. Bei dem OpenWMS.org Framework hatte ich zu Anfang auf "Standard-Technologien" gesetzt, um natürlich eine lange Wartbarkeit und Langlebigkeit vorhandener Projekte zu garantieren. Damals war JavaServer Faces in der Version 1.1 der de-facto Standard (2005). Dieses Projekt fand leider niemals seinen Weg aus einem Developer-Branch heraus. Trotzallem wollte ich an dem Standard festhalten und entwickelte mit JSF1.2 sowie der RichFaces Library eine zweite Version. Diese kam mit Ajax Features daher und machte das Ganze etwas mehr "Rich" als es mit plain JSF einher kam. Das Problem was sich damals und bis heute noch nicht gelöst hat ist, dass es schier einen enormen Zeitaufwand bedeutet "custom"-Screens zu entwickeln. Das sind genau die Dialoge die nicht in irgendein Template passen. Im Falle eines WMS (Warehouse Management System /logistics) Projektes ist dies eben keine Seltenheit. Wir entwickeln kein breit-bekanntes Softwareprodukt, nachdem sich der Kunde ausrichten muss. Vieles ist weit weg von Standardsoftware mit Standard-Dialogen.
Das Problem bis zu dem damaligen Zeitpunkt war einfach, dass Browser-Inkompatibilitäten einen enormen Aufwand an Screen-Design benötigten. Sprich, ein Entwickler musste (und muss immer noch) die Technologien CSS, JavaScript indeep beherrschen! Was an sich eine Lachnummer ist. Ein WMS Projekt Engineer möchte eigentlich nur seine Geschäftslogik einfach und verständlich umsetzen - ohne ein Webdesigner sein zu müssen.
Nachdem ich selbst einen grossen Teil des eigentlichen OpenWMS.org Frameworks mit JavaServer Faces 1.2 und RichFaces implementiert hatte, musste ich wieder einmal feststellen, dass der hochgelobte Standard nicht die richtige Technologie für meine Domäne ist.
Mir wurde klar, dass zum einen eine vernünftige Tool-Unterstützung fehlt, und zum anderen die Inkompatibilitäten der "Sandboxes" (Browser) ein erhebliches Problem darstellt.
Zum Glück gab es Adobe Flex!
Adobe Flex bietet den Vorteil, dass auch eine Sandbox von Adobe geliefert wird (Adobe Flash Player). Zudem bietet Adobe eine ordentliche IDE (Adobe FlexBuilder 3 dazumals) die es erlaubt UI vernünftig in angemessener Zeit zu implementieren. Rapid Screen Development!
Flex heisst ActionScript mit MXML, und wo ist Java?
Die Businesslogik eines WMS Projektes sollte über mehr als 10 Jahre wartbar sein. Das UI darf in dieser Zeit öfters als einmal wechseln. Also stellen sich zwei Fragen:
1) Wie stabil sind die Interfaces des Backends (not a topic here)?
2) und wie gut ist die Anbindung an Backend-Technologien vorhanden?
Im Falle von Adobe Flex kann man auf die zweite Frage antworten: Die Anbindung an die Java Welt funktioniert mit Frameworks wie GraniteDS perfekt und mit Adobe BlazeDS und Adobe Cairngorm auch sehr gut.
Trotzallem 2012.
Adobe hat sich leider dazu entschieden, sicherlich aus Gründen der kommenden HTML5 Bewegung, das Flex Framework an die OO Community zu übergeben und nicht mehr selbst voran zu treiben. Was für mich persönlich den Ende, bzw. die nicht mehr aktive Weiterentwicklung, des Frameworks bedeutet.
Also habe ich mich erneut dazu entschieden, eine Vorab-Evaluation über gewisse, bekannte Web-Frameworks zu betreiben. Meine Anforderungen hatten sich eigentlich nicht verändert: Die Entwicklung der Screens sollte ein Software Engineer, der halbwegs die laufenden Technologien beherrscht, in angemessener Zeit umsetzen können.
Ein weiterer Versuch mit JSF2
No way. Um diesen Blog abzukürzen möchte ich mich kurz fassen. Nach Flex (und FlexBuilder) hatte ich mit Eclipse und dem XML-Editor (mit XML-Tag completition) das Framework nachgebaut. Sprich: Basis-Framework (Web Projekt) und pro Modul (CORE, COMMON, TMS, WMS) das entsprechende Web-Projekt. Verwendet hatte ich diesesmal die PrimeFaces Komponenten-Bibliothek in Version 3.2. Ergebnis: Es ist immer noch sehr sehr zeitaufwändig, Dialoge mit JSF umzusetzen. Ich kann einem Software Engineer (nicht zu vergessen: der eigentlich projekt-spezifische Business-Screens implementieren möchte) diese Technologie in Version 2.1 nicht in die Hand geben - das Budget würde bei Weitem überzogen werden.
Hin und wieder hatte ich auch mal das sehr vielversprechende Vaadin Framework angeschaut. Leider ist hier die Integration in Applikations-Frameworks weniger gut gegeben. Dependency Injection funktioniert eben nur unter Krämpfen und Umwegen. Ebenso ist die Integration eines Security Mechanismus sehr aussenstehend. Wer eine einfache Seite nachbauen möchte, die einen Image-Button beliebiger Grösse beinhalten soll und dieser Button zudem noch einen Mouseover-Effect bietet dem sei dieses CSS von der Original Vaadin Page angetan (bitte unten weiterlesen):
.toolbar .v-button {
display: block;
height: 55px;
background: transparent;
border: none;
text-align: center;
}
.toolbar .v-button img {
display: block;
margin-left: auto;
margin-right: auto;
margin-bottom: 5px;
}
.toolbar .v-button span {
font-size: x-small;
text-shadow: #fafafa 1px 1px 0;
}
.toolbar .v-button .v-button-wrap,
.toolbar .v-disabled.v-button .v-button-wrap {
background: transparent;
border: none;
-webkit-border-radius: 0;
-moz-border-radius: 0;
border-radius: 0;
-webkit-box-shadow: none;
-moz-box-shadow: none;
box-shadow: none;
}
.toolbar .v-button:active .v-button-wrap,
.toolbar .v-button.v-pressed .v-button-wrap {
background: transparent;
-webkit-box-shadow: none;
-moz-box-shadow: none;
box-shadow: none;
}
CodeLympics 2012
Zu diesem Projekt hatten wir uns zu Viert arrangiert. In 4 Wochen, innerhalb 3 Sprints und 3 Demos vor einer Jury eine Web-Anwendung zu entwickeln die:
- sexy, intuitiv und rich sein soll,
- reliable und robust sein soll
- ohne Browser Plugin auskommt
- und im IE8 laufen soll
aber weder
- wartbar
- noch langlebig
sein soll
Also Rapid Application Development. Die Wahl auf PrimeFaces 3.2 stellte sich als Blamage heraus, da wegen Problemen mit JavaScript, jQuery und & Co. das alles nicht lief.
Technologien wie JavaFX nehme ich hier bewusst nicht in Betracht, da zum Ersten widerum eine "Sandbox" verwendet wird, zum Zweiten keine ordentliche Toolunterstützung vorhanden ist und zum Dritten keine besondere Stabilität bzgl. der Wartbarkeit in Betracht auf vorgängige Versionen vorhangen ist (man vergleiche v1.1, v1.2 und v2.0).
