Stück für Stück bin ich dabei meine Webseiten weg vom alten Tabellen orientierten hin zu reinen CSS Lösungen zu entwickeln. Immer wieder trifft man dabei aber auch auf ungewohnte Schwierigkeiten.
Ich wollte einen Text und ein Bild nebeneinander setzten, so dass das Bild links und der Text rechts steht. Soweit alles kein Problem, nun sollte aber der Text eine graue Hintergrundfarbe haben, die logischerweise den gesamten Bereich ausfüllt. Da mein Text aber u.U. länger ist als das Bild hoch ist, u.U. aber auch umgekehrt suchte ich nach einer Lösung die das entsprechende DIV auf eine Höhe von 100% bringt.
Letztendlich vergeblich, für das Problem scheint es nur zwei Lösungen zu geben, die aus meiner Sicht beide Workarounds sind:
- Man fügt eine Hintegrundgrafik mit verschiedenefarbigen Bereichen in das gesamte Element ein, und erhält dann Pseudospalten wie man es hier sehen kann.
- Man kann sagen welche der beiden “Spalten” garantiert eine ausreichende Länge hat, und kann dann mit einer verschachtelten Lösung wie sie hier beschrieben ist leben.
Obwohl ich mich nun schon seit über 2 Jahren mit JSF befasse gibt es doch immer wieder spannende Neuigkeiten. War ich am Anfang von der Entwicklungsgeschwindigkeiten und der Kapselung im Komponenten sehr begeistert, reift für mich Stück für Stück die Erkenntnis das JSF noch um einiges weiter entwickelt werden muss.
Heute sollte ich eine komplexe JSF Anwendung untersuchen, von der der Kunde behauptet, sie würde zu schlecht skalieren. Im Rahmen der üblichen Verdächtigen in Bezug auf JEE Applicationen habe ich mir mal die HTTP Session angesehen und prompt hatte ich den schuldigen. Die Standardimplementierung (SUN Reference Implemtation 1.1) speichert zur Wiederherstellung des Zustands schlichtweg den kompletten Komponenten Baum mit Hilfe von Standard Java Serialisierung in der Session. Beim Server State Saving auf dem Server sonst auf dem Client. Klingt ja erst mal nach einer guten Idee, wenn man aber bedenkt wieviele Komponenten eine halbwegs komplexe Seite haben kann und wieviel Speichert das braucht, sieht man dass da ruck zu hunderte von Kilobyte oder teilweise sogar Megabyte (!) in der Session landen. Wenn man nun noch bedenkt, dass standardmäßig die letzten 15 Views in der Session gehalten werden. Logisch also das ich bei 100 oder mehr parallelen Session dieser Größen Ordnung schnell an die JVM Grenze komme und eine Skalierbarkeit nicht mehr gegeben war.
Irgendwie erschreckend, jedem der neu mit Java Web Entwicklung beginnt sage ich “Speicher so wenig wie möglich in der HTTP Session” und dann kommt SUN mit einem Standard Web Framework daher und baut dass. Gegenüber dem Komponent Tree machen die einfachen Nutzobjekte (und das waren in der Anwendung nicht wenige) nicht mal 5% des Speicherplatz aus. Es wird höchste Zeit das SUN hier nachlegt und ein delta Handling, transiente Objekte und ähnliches einführt damit man JSF auch wirklich in größeren Web Anwendungen verwenden kann. Ausserdem muss hier generell überdacht werden, ob ich informationen die ich hart in JSP Seiten kodiere wirklich bei jedem Request neu Serialisieren muss. Gute Ideen gibt es genug, hoffentlich fließt davon einiges in JSF 2.0 ein.
Nachdem dieses Blog eine Weile “Out of the box” lief habe ich jetzt mal ein paar Dinge nachgezogen und Plugins installiert. Ich bin immer wieder begeistert wie einfach doch ein gutes Plugin System funktionieren kann. Ein paar Dateien auf dem Server kopieren und gut ist.
Wenn ich dann daran denke wie schwierig es manchmal sein kann ein JAR in eine Anwendung einzubinden… Gut ich vergleiche hier Äpfel mit Birnen aber was die Handhabbarkeit von PHP an dieser Ecke anbetrifft kann man sich nicht beschweren. Unter Java hat lediglich die Eclipse Plattform (IDE und RCP) einen ähnlich guten (vielleicht sogar besseren?) Update Mechanismus.
In der letzten Woche hatte ich eine interessante Diskussion mit einem Arbeitskollegen. Ausgehen von einem konkreten Problem kamen wir nach und nach zu einer Recht fundamentalen Diskussion über das Pro und Contra des Model View Controller (MVC) Ansatzes für Web Anwendungen.
Nachdem ich anfangs fast automatisch in die übliche Schema gefallen bin, alles bisherige zur verteidigen, wurde mir Schritt für Schritt bewußter, dass ich das ganze nie wirklich hinterfragt hatte. Spätestens seit den Zeiten von Struts 1.x war MVC für mich eigentlich gesetzt und im Laufe der Zeit hat es sich so sehr festzementiert, dass ich mir Web Entwicklung ohne MVC fast nicht mehr vorstellen kann.
Nach der Diskussion habe ich dann mal im Web recherschiert, in der Tat scheinen 99% aller Java Web Frameworks (und davon gibt es ja nun wahrlich genug) auf dem MVC Pattern zu beruhen und Kritik oder alternative Ansätze gibt es wenig. So musste ich eine ganze Weile suchen bis ich diesen Blogeintrag entdeckt habe.
Sind wir mal ehrlich, alle die wir schon einmal eine Web Anwendung geschrieben haben wissen: Es gibt nur eine View: HTML. Alle Beispiele für alternative Ausgabekanäle (WAP; XML…) sind konstruiert oder haben ein sehr begrenztes Anwendungsszenario. Zudem sind die Anforderungen die das Netz mit sich bringt oft so speziell dass auch der Controller ohne Web keinen Sinn macht. Also können wir die ganze Diskussion über Austauschbarkeit und Wiederverwendbarkeit mal getrost der Wissenschaft überlassen. Bleibt noch die Wartbarkeit, bekanntlich soll der Code ja leicht zu ändern und gut zu pflegen sein. Aber sauber organisierter Code muss nicht gleich MVC heissen, im Gegenteil manchmal steht MVC der Wartbarkeit sogar entgegen.
Das soll jetzt keine Predigt gegen MVC an sich sein, aber jedes Muster sollte man nur dann anwenden wenn es passt. Mit der Zunahme von Mashups und anderern Aggregationstechniken, einem starken Innovationsdruck von Seiten der Skriptsprachen her und den immer dynamischeren Applikationen (Web 2.0) darf MVC kein heiliger Gral sein. Für mich ist MVC kein Selbstzweck, vielleicht darf es manchmal noch einfacher sein, schließlich ist ja bekanntlich gut, gut genug.
Zur Zeit beschäftige ich mich mal wieder mit dem Thema (Web) Content Management Systeme und als Java Entwickler trifft man dann früher oder später auf JSR 170 (Java Content Repository). Bisher war mir irgendwie immer nicht ganz klar was das ist und wozu das gut sein soll.
In den letzten Tagen ist da jetzt aber endlich mal ein bisschen Licht ins Dunkel gekommen. Die JSR-170 beschäftigt sich nicht mit Content Management in dem Sinn, es ist keine API für Content Management Systeme, sondern eine API für ein Content Repository.
Größtes Problem für mich als deutschsprachiger Java Entwickler, war dass ich Content Repository nicht vernüftig übersetzt bekommen (“Inhaltsverzeichnis” ist wohl nicht brauchbar). Worum geht es also?
Es geht um eine API um Daten zu speichern, nicht mehr und nicht weniger. Ein System das JSR-170 unterstützt unterstütz also einen bestimmten Zugriff auf die Klassen, so wie eine relationale Datenbank i.d.R. SQL als Abfragesprache für seine Daten unterstützt, unterstützt ein solches System eine bestimmte API um auf seine Daten zugreifen zu können. Die Daten werden dabei allerdings nicht relational sondern (logisch) hierarchisch gespeichert.
Die JSR-170 gibt es in zwei (Basis) Leveln die jeweils verschiedene Fähigkeiten beinhaltet, auf Level-1 ist nur lesender Zugriff möglich, erst auf Level-2 kann man auch Daten schreiben. Hat man also ein System das JSR-170 Leve-2 implementiert, kann man es auf diesem Wege mit Daten befüllen und auch auf die Inhalte zugreifen.
Die API ist also eher ein Ersatz für eine Datenbank oder eine proprietäre Speicherung im Filesystem als eine API für Content Management Systeme. Ein ganz gute Abgrenzung findet sich bei der Firma Day Software AG in diesem PDF Dokument.