Wicket 1.4 nähert sich der Fertigstellung. Das ist ein gutes Zeichen, auch wenn ich Wicket 1.4-rc2 bereits längere Zeit ohne Probleme produktiv einsetze. Dieses Jahr wird ein Wicket-Jahr, denn so langsam beschäftigen sich immer mehr Entwickler mit dem Framework. Außerdem erscheinen in diesem Jahr einige Bücher rund um Wicket, so dass man gespannt sein darf, welche Auswirkung aktuelle Literatur zu diesem Thema haben wird.
Für mich steht diese Jahr auch im Zeichen von Scala. Die IDE-Unterstützung verbessert sich zunehmen, so dass man jetzt schon wieder zwischen Eclipse und Netbeans wählen kann. Wenn man dann Scala mit Wicket kombiniert, könnte man bei der Umsetzungsgeschwindigkeit auch Frameworks wie Grails den Platz auch gerade bei einfachen Projekten streitig machen. Das Wicket gerade bei komplexen Projekten punktet hat sich zwar auch noch nicht überall herumgesprochen, aber je mehr Anwendungen mit Wicket realisiert werden, desto schwieriger kann man diese Entwicklung ignorieren.
Damit bleiben für mich zwei Technologien übrig, mit denen man sinnvoll Java-basierte Webanwendungen entwickeln kann: GWT und Wicket. Für alle anderen Frameworks gibt es eigentlich keine Berechtigung, weil es keine guten Gründe mehr gibt, die für deren Einsatz sprechen. Wer andere Meinung ist, kann sich ja in einem Kommentar beschweren.
Am Ende des Jahres werden wir sehen, wie dicht ich dran lag:)
Wenn man deine Aussage auf Core-Applications beschränkt, kommt für mich sogar nur Wicket in Frage. GWT mit seiner extremen JS-Konvertierung geht für mich vom Konzept her eher in Richtung Flex/Silverlight/JavaFX, auch wenn ich dafür kein Plugin benötige.
Leider ist man ja aber bei komplexen Portal-Anwendungen, wie sie im Feld der Webapplications ja eher die Regel sind, auf ganz andere Frameworks angewiesen (Liveray, OpenCms, …), so das man die Aussage sicher nicht ganz so allgemein stehen lassen kann.
In Portal-Umgebungen oder im Zusammenhang mit einem wie auch immer gearteten CMS wird es natürlich recht schnell unangenehm. Interessant wäre dabei die Wicket-Portlet-Unterstützung, die ich in Zukunft mal testen werde. Ansonsten stelle ich mir immer öfter die Frage, ob die Verschmelzung mit einem CMS nicht mehr Nach- als Vorteile verursacht. Gerade weil man mit Wicket doch recht komplexe Anwendung realisieren kann, wäre eine vielleicht denkbare Alternative die Erfassung strukturierter Informationen, die dann durch Wicket an den gewünschten Stellen dargestellt werden. Interessant wäre auch ein Live-Edit-Modus, der es Redakteuren ermöglicht, in grenzen auf die Darstellung und Anordnung Einfluss nehmen zu können. Dabei steht dann zwar nur die Flexibilität zur Verfügung die die Anwendung bereitstellen würde, könnte aber auf diese Weise auch Fehlbedienungen eindämmen.
In der Realität ist es nie so schön, wie man es sich in seinem Kopf zusammengebaut hat. Wicket ist aber flexibel genug, dass man doch recht eindrucksvoll Brücken zwischen beiden Welten bauen könnte.
Apropos CMS: BRIX CMS. Noch keine eigenen Erfahrungen gesammelt, Zeit reicht im Moment nicht aber ich schiele jede paar Tage in diese Richtung…
Meiner Meinung nach ist Integration von Wicket-Anwendungen in anderen Frameworks/Portalen nicht komplizierter als für andere WebFrameworks.
Bin auch der Meinung daß dieses/nächstes Jahr Wicket-Jahre werden können. Vorletzte Woche habe ich die erste Stellenanzeige (oder Projektanfrage?) mit Wicket-Anforderungen gelesen, iirc im Raum München. Es geht los