# Verständnis-Frage zu den vielen Frameworks



## Fats (22. Jul 2008)

Hallo miteinander!

Mir schwirrt vor lauter Frameworks und Tools der Kopf und muß mich daher dringend mal austauschen. Es gibt JSF, Spring, Seam, Groovy, Wicket, Hibernate und sicherlich noch gaaanz viel mehr. Sich in alles einzuarbeiten wäre vermutlich overkill, wenn man bedenkt, daß alleine JSF ein Projekt von zwei, drei Monaten sein soll. 

Ich hab so das eine oder andere angelesen, aber blicke noch nicht so ganz, was nun genau wofür ist. JSF ist vorrangig für die Entwicklung von Webinterfaces (Formularen und Co), richtig? Spring ist was eigenes. Vereinfacht das die Kommunikation mit der DB? Das wäre doch eigentlich Hibernate, oder? Hmmm .. versteh ich noch nicht so recht! Aber Spring kann immerhin mit JSF kombiniert werden! Ist das denn wirklich sinnvoll? 
Seams scheint alles zu kapseln aber basiert irgendwie doch wieder auf JSF. Und Hibernate übernimmt das Speichern in der DB. So ganz grob.

Dann gibt s noch Groovy - was mir eher nach einer eigenständigen (javartigen) Sprache aussieht - und Wicket. Letzteres ist scheinbar auch wieder das Über-Framework der Frameworks, das wieder alles abstrahiert....

Wann setzt man jetzt was am sinnvollsten ein? 

Mein Ziel: Webanwendungen entwickeln. Kleine Webseiten, kleine Communities, mal Richtung Shop, mal Richtung CMS. Ich werde sicherlich  in näherer Zukunft keine Systeme für die "Deutsche Bank" oder ähnlich große Unternehmen entwickeln.  Ich kann auch nicht ein Jahr fulltime in "Lernen" investieren - auch wenn s cool wäre  

Meine Erfahrungen: (OO) Programmieren, Java, JSP und Tomcat kein Problem, auch MySQL Anbindung im klassischen Stil kein Ding. 

Was würdet ihr mit eurer Erfahrung mir raten?

Viele Grüße
Fats


----------



## BjörnBu (22. Jul 2008)

Groovy ist eine Skriptsprache und sehr häufig sehr hilfrecih aber meiner Meinung nach definitiv kein EE Kernthema

JSF ist tatsächlich für webinterfaces zuständig.

Hibernate ist ein O/R-Mapper und erlaubt direkt Objekte/Tabelle zu mappen ohne aus einer Tabell die Spalten zu beziehen udn dann damit händisch Objekte zu instanzieren.

Seam ist eine Art komplettlösung für EE Webapps. Grade wenn einfach nur eine typische EE Webapp erstellt werden soll, geht es mit Seam shcnell und sieht hübsch aus. Wenn viele Extrawünsche folgen, kann Seam aber auch zum Problem werden, dass es einem ein ganz bestimmtes Design "aufzwingt". Alles was von Seam untersützt wird geht damit super, alles weitere wird zum Horror. (persönliche Meinung)
Dabei basiert Seam zwangsläufig auf JSF und Hibernate (glaube hibernate lässt sich durch JPA ersetzen aber das Prinzip bleibt das gleiche).

Spring ist schwer zu erklären. Schließlich gibt es sogar ein Posting von Rob Johnson (SpringSource-Chef) das da heißt "Rod Johnson: 2006 the year Spring became Ubiquitous".

Allgegenwärtig also... Tatsächlich war Spring mal eine ALternative zu den furchtbaren EJB 2.x's. Mitlerweile gibt es fast für alles erdenkliche eigene Teilprojekte und lässt sich super mit andern wichtigen Frameworks wie eben auch JSF und Hibernate verbinden. Das schöne ist, dass Spring besonders viel Wert darauf legt nicht invasiv zu sein, also möglichst wenig Abhängigkeiten im Code zu Spring selbst zu versuchen. Außerdem zeichen sich quasi alle teilprojekte durch sehr gut durchdachtes Design aus.

Um ein Verständis für Spring zu bekommen, solltest du dir auf jeden Fall zuerst den Dependency Injection Teil anschauen. genau das ist eigentlich der Knackpunkt. 
Ein weiteres großes Thema ist AOP. Aber obwohl es stark in den weiteren Modulen genutzt wird, kannst du es erstmal außen vor lassen, finde ich


----------



## Helios4711 (22. Jul 2008)

Hier mal ein Vergleich von Wicket und JSF:

http://ptrthomas.wordpress.com/2007/05/14/a-wicket-user-tries-jsf/

Ist zwar auf English aber es gibt einen Haufen Bilder 

Gruß,

Helios


----------



## Fats (22. Jul 2008)

Hey, vielen Dank! Also an Spring geht vermutlich kein Weg vorbei, oder? ;-) Wie ist das mit Wicket? Wie ausgereift ist das? Hab gelesen, daß die Doku abgesehen von den Tutorials bei apache nur sehr dürftig ist ... 

Wie ist das bei Seam mit dem "Zwang beim Design" gemeint? Ist das so ähnlich wie z.B. bei Liferay, wo man am besten fährt, wenn man nix ändert? Aber wehe, wenn man ein eigenes Portlet mit eigenem Layout und eigenen Funktionen haben möchte ...  

Fats


----------



## BjörnBu (22. Jul 2008)

An Spring führen schon Wege vorbei. Seam wäre einer. Ich persönlich bin aber Spring-Fan.

Mit dem Zwang beim Design meinte ich eher sowas:

In Seam sind (viele/alle? ich weiß nicht genau) SessionBeans stateful. Außerdem wird wichtige Business in "Conversations" ausgeführt. Alles wunderbar wenn man 'ne Webapp baut, wie Seam es will.

Braucht plötzlich die Anwendung eine Webservice Schnittstelle, steht man dann da und muss fast alles neu (= DOPPELT)implementieren. Eigentlch lässt sich dann fast nur das blutleere Domain Model (die paar Entities) wieder verwenden.

Seine Webapp kann man sehr schön customizen. Aber beim allgemeinen Aufbau deiner Applikation bekommst du sehr fest vorgeschrieben, welche Layer es zu geben hat und welche Technologie auf welcher Ebene genutzt werden muss.


----------



## deamon (22. Jul 2008)

Hallo Fats,

ich kann mir vorstellen, wie dir zumute ist ... Die Vielzahl an Frameworks ist schon erschlagend, perfekt ist keins und die Versuchung, ein vermeintlich besseres auszuprobieren immer groß (das Gras ist immer auf der anderen Seite des Zauns grüner). 

JSF ist ein Framework, das Oberflächenkomponenten für Webanwendungen bereitstellt. Optimiert wurde es für Werkzeugeinsatz, wofür aus meiner Sicht nicht tragbare Kompromisse eingegangen wurden. JSF bringt auch noch etwas für die Valdidierung und die Ablaufsteuerung (Controller) mit. Die Nachteile sind, dass ohne JavaScript praktisch gar nichts geht, dass man im URL nicht unbedingt sieht, wo man gerade ist, was auch bedeutet, dass Suchmaschinen kaum eine Chance haben und auch Lesezeichen nicht unbedingt gesetzt werden können. Die Validierung von Eingabedaten gehört aus meiner Sicht auch nicht in die Präsentationsschicht. Ich habe mir JSF mal angesehen und habe aufgrund dieser Mängel die Finger davon gelassen. Die Performance ist auch umstritten.

Spring ist ein Framework, was grundlegende Dinge anbietet, die dann zum Aufbau der eigentlichen Anwendung dienen. Mit Depency Injection werden lose gekoppelte Objekte elegant verdrahtet und mit Aspektorientierter Programmierung werden Querschnittsfunktionen wie Sicherheit, Transaktionen, Protokollierung usw. elegant vom fachlichen Code getrennt. Das sind die beiden grundlegenden Teile von Spring. Außerdem ist Spring aber noch ein Meta-Framework, das die Nutzung weiterer Frameworks wie JDBC, Hibernate, Servlets usw. vereinheitlicht und vereinfacht. Das schöne daran ist, dass man nur soviel davon benutzen kann, wie man will und sich Spring kaum auf den Code auswirkt.

Für deinen Zweck ganz interessant könnte Grails sein (siehe auch http://www.groovy-forum.de/). Da wird Spring und Hibernate  mit der Skriptsprache Groovy kombiniert. Durch sinnvolle Vorgaben (Konvention vor Konfiguration) wird die Arbeit deutlich erleichtert und beschleunigt.


----------



## ps (22. Jul 2008)

Wenn du Webanwendungen entwickeln möchtest - schau doch auch mal bei Struts2 vorbei:
-> http://struts.apache.org/2.x/

Du musst dir aber vorerst eine ganz wichtige Frage stellen:
Möchtest du Actionbasiert oder Ereignisorientiert entwickeln? Actionbasiert ist der "herkömmliche" Weg, bei welchem du mit Aktionen, Requests, Responses, etc arbeitest.
Der Komponentenbasierte Ansatz ala JSF, Wicket, Tapestry, etc abstrahieren dir das alles weg und du entwickelst wie auf dem Desktop ereignisorientiert (Benutzer hat dort hingeklickt, etc). Das erkauft man sich aber mit einer wesentlich schlechteren Performance und hohem Speicherverbrauch. 

Meine Meinung: Komponentenbasiert ist Prima für Adminpanels, für Intranet Anwendungen und überall wo du auch eine Desktopapplikation schreiben könntest. Actionbasiert ist der Weg wenn man ein Internetportal erstellen möchte. Aber das ist nur meine persönliche Meinung.

Struts2 ist meine Wahl geworden weil es unheimlich flexibel ist - man kann zB. auch GWT oder JSF Anwendungen integrieren und das Struts2 Backend verwenden. Es setzt sehr stark auf Convention-over-Configuration und hat in dieser Beziehung sehr viel von Ruby on Rails gelernt. Man kann seine Controller in Groovy, JRuby, oder einer beliebig anderen Scriptsprache schreiben (wenn man möchte). Alles in allem hat man damit ein sehr flexibles Werkzeug an der Hand - und es ist ein WEBframework. Ob ich einen Webservice baue, ein REST interface, ein Formular oder eine relativ statische Seite: Struts2 unterstützt mich dabei. Bei JSF und anderen Komponentenbasierten Frameworks muss man hierfür oftmals Verrenkungen vollführen.

Am Ende bleibt es eine Frage der Anforderungen


----------



## Guest (22. Jul 2008)

Ein weiteres Framework was nocht nicht genannt wurde ist Struts2. 

Ich benutze zur Zeit das Gespann Struts2 + Spring + Hibernate und bin sehr zufrieden damit.


----------



## Guest (22. Jul 2008)

Ups, da war jemand schneller


----------



## deamon (22. Jul 2008)

Anonymous hat gesagt.:
			
		

> Ich benutze zur Zeit das Gespann Struts2 + Spring + Hibernate und bin sehr zufrieden damit.



Ohne mich mit Struts beschäftigt zu haben: was ist für dich der Vorteil gegenüber Spring MVC?


----------



## ps (22. Jul 2008)

deamon hat gesagt.:
			
		

> Ohne mich mit Struts beschäftigt zu haben: was ist für dich der Vorteil gegenüber Spring MVC?



Da ich Spring MVC nicht kenne, kann ich dir nicht sagen ob es mir erlaubt:
- meinen DI Container frei zu wählen (Guice, Spring, Plexus, etc)
- Convention over Configuration zu benutzen (Keine Konfiguration von Actions, Templates, Results notwendig).
- mit REST zu entwickeln - 100% kompatibel zu RoR
- meine Controller/Actions in einer Scriptsprache zu schreiben (JRuby, Groovy, etc)
- meine eigenen Tags/Themes zu entwickeln (und diese in FreeMarker, Velocity oder JSP Templates zu benutzen)
- Validierung mit AJAX, auf Client- und/oder Serverseite.
- andere Technologien einzubinden und meine Actions auf Serverseite zu benutzen (GWT, Grails, JSF, etc)

Für mich wiegt am meisten das mich Struts2 nicht zwingt Spring zu benutzen ;-) *SCNR*


----------



## Fats (23. Jul 2008)

Mojn  

Vielen Dank für die vielen Gedanken! 



			
				ps hat gesagt.:
			
		

> [...]
> Meine Meinung: Komponentenbasiert ist Prima für Adminpanels, für Intranet Anwendungen und überall wo du auch eine Desktopapplikation schreiben könntest. Actionbasiert ist der Weg wenn man ein Internetportal erstellen möchte. Aber das ist nur meine persönliche Meinung.[...]



ps, kannst Du sagen, was Dich zu dieser Meinung bewegt hat? Warum denkst Du, daß komponentenbasiert für Adminpanels und Intranet geeigneter ist und actionbasiert besser für Internetportale? Warum ist dem so? Welche Erfahrungen hast Du gemacht?

Viele Grüße 
Fats


----------



## Helios4711 (23. Jul 2008)

Für Wicket gibt zum Beispiel hier ne ausführliche Doku:

http://www.wicket-library.com/wicket-examples/

ausserdem such mal ne ebook pro wicket

Gruß,

Heli


----------



## ps (23. Jul 2008)

Fats hat gesagt.:
			
		

> ps, kannst Du sagen, was Dich zu dieser Meinung bewegt hat? Warum denkst Du, daß komponentenbasiert für Adminpanels und Intranet geeigneter ist und actionbasiert besser für Internetportale? Warum ist dem so? Welche Erfahrungen hast Du gemacht?



Nun, zum einen ist das komponentenbasierte Modell wahnsinnig ressourcenfressend. Es muss sich stets den Zustand der Komponenten merken - das kostet Speicher. Im Java Magazin war mal ein schöner Artikel darüber.. Struts war wenn ich mich richtig erinnere fast viermal schneller als JSF.

Ich weiß nicht wie es mittlerweile mit der Link Problematik aussieht - als ich mit JSF gespielt habe musste man ziemlich üble Hacks anwenden nur um die Seite suchmaschinenfreundlich zu bekommen. In wie weit Seam hier Besserung geschaffen hat weiß ich nicht. Bei Wicket ist das glaube ich gut gelöst worden.

Meine Erfahrung ist das man in einem Internetportal früher oder später den einen oder anderen Webservice aufsetzen möchte, einen RSS Feed, evtl. einen Bereich für mobile Endgeräte. Ein komponentenbasiertes Modell unterstützt mich an dieser Stelle überhaupt nicht.


----------



## robertpic71 (23. Jul 2008)

@ps
Gute Ausführungen, welchen ich weitgehend zustimmen kann, aber



			
				ps hat gesagt.:
			
		

> .
> Ich weiß nicht wie es mittlerweile mit der Link Problematik aussieht - als ich mit JSF gespielt habe musste man ziemlich üble Hacks anwenden nur um die Seite suchmaschinenfreundlich zu bekommen.


Hierbei ist noch zu erwähnen, dass die Suchmaschinen sowieso schnell aussteigen, sobald parametergesteuerte Seiten erzeugt werden. 



			
				ps hat gesagt.:
			
		

> Meine Erfahrung ist das man in einem Internetportal früher oder später den einen oder anderen Webservice aufsetzen möchte, einen RSS Feed, evtl. einen Bereich für mobile Endgeräte. Ein komponentenbasiertes Modell unterstützt mich an dieser Stelle überhaupt nicht.


Hier noch eine Ergänzung, ohne jetzt die Spring Diskussion wieder aufflamen lassen zu wollen: Aber genau dabei kann doch Spring helfen. Es kann die Logik/BusinesBeans in die Webapplikation "einpflanzen" und auch als Webservice (Spring WebService) verkaufen. 

Noch zu den neueren (ZK, Wicket, Echo2, nicht unbedingt JSF) komponentenbasierenden Frameworks: Diese versuchen weitgehend das Desktopmodel nachzubilden. Meistens kann man Komponenten im Swinglike erzeugen wie z.b. new Button("Speichern"). Desweiteren bleibt einem bei diesem Framework, so manche Webkomplexität erspart. Da diese Frameworks, wie von ps schon angedeutet, nur Hilfestellung für den "Viewteil" liefern, ist die Einarbeitung nocheinmal kürzer. Ein Desktopprogrammierer wird hier schnell Ergebnisse zuwege bringen.

/Robert


----------



## Guest (23. Jul 2008)

@WebServices

WebServices sind nicht abhängig vom GUI-Framework. Wenn die Geschäftslogik nicht mit der Präsentationslogik vermischt ist, ist es an sich kein Problem die Geschäftslogik als WebService anzubieten. Man muss halt vorher darauf achten, wohin man was verteilt.

Zudem kann man auch bei den komponentenorientierten Frameworks immer noch ein Servlet für den WebService einziehen.

Bei JSF und Wicket ist es auch kein Problem RestFul-Services anzubieten. 

Gruß,

Peter


----------



## Fats (25. Jul 2008)

Ich sag mal zwischendurch danke für die vielen Anregungen und Informationen!  

Viele Grüße
Fats


----------



## Guest (7. Aug 2008)

Hallo zusammen,

ist jetzt zwar schon ein paar Tage her, allerdings möchte ich kurz auf ein paar Fehlinformationen zu JSF eingehen.



			
				deamon hat gesagt.:
			
		

> Hallo Fats,
> JSF ist ein Framework, das Oberflächenkomponenten für Webanwendungen bereitstellt. Optimiert wurde es für Werkzeugeinsatz, wofür aus meiner Sicht nicht tragbare Kompromisse eingegangen wurden. JSF bringt auch noch etwas für die Valdidierung und die Ablaufsteuerung (Controller) mit. Die Nachteile sind, dass ohne JavaScript praktisch gar nichts geht, dass man im URL nicht unbedingt sieht, wo man gerade ist, was auch bedeutet, dass Suchmaschinen kaum eine Chance haben und auch Lesezeichen nicht unbedingt gesetzt werden können. Die Validierung von Eingabedaten gehört aus meiner Sicht auch nicht in die Präsentationsschicht. [..] Die Performance ist auch umstritten.





			
				ps hat gesagt.:
			
		

> Nun, zum einen ist das komponentenbasierte Modell wahnsinnig ressourcenfressend. Es muss sich stets den Zustand der Komponenten merken - das kostet Speicher. Im Java Magazin war mal ein schöner Artikel darüber.. Struts war wenn ich mich richtig erinnere fast viermal schneller als JSF.
> 
> Ich weiß nicht wie es mittlerweile mit der Link Problematik aussieht - als ich mit JSF gespielt habe musste man ziemlich üble Hacks anwenden nur um die Seite suchmaschinenfreundlich zu bekommen. [..]
> 
> Meine Erfahrung ist das man in einem Internetportal früher oder später den einen oder anderen Webservice aufsetzen möchte, einen RSS Feed, evtl. einen Bereich für mobile Endgeräte. Ein komponentenbasiertes Modell unterstützt mich an dieser Stelle überhaupt nicht.



Ich fasse nochmal die zu Felde getragenen Kritikpunkte:

1.) Validierung/Konvertierung haben nichts in der Präsentationsschicht zu suchen.

Diese Aussage stimmt in den meisten Fällen, allerdings ist es in JSF kein muss, diese Möglichkeiten zu nutzen. Man kann die Validierung auch in der Geschäftslogik durchführen und dann entsprechend programmatisch Fehlerhinweise erstellen. Bei der Anzeige dieser Fehlermeldungen werden wir jedoch in beiden Fällen (sowohl über JSF-eigene Validatoren als auch beim programmatischen Ansatz) von JSF unterstützt (man kann weiterhin h:message nutzen).

2.) Ohne JavaScript geht gar nichts.

Diese Aussage ist schlicht und ergreifend falsch. Benutzt man die JSF-RI oder das Pendant Apache MyFaces, kommt man komplett ohne JavaScript aus. Lediglich wenn man sich ajaxifizierte Zusatzkomponenten ins Boot holt (Oracle ADF Faces, JBoss RichFaces, a4j, IceFaces etc.), wird Output erzeugt, der mit JavaScript angereichert ist (ist aber bei jedem anderen Webframework der Welt auch so, will ich ajaxifizierte Controls haben, benötige ich JavaScript). Den Vorteil, den ich hier sehe ist der, dass ich mit JavaScript nicht in Berührung komme und schon fertige Komponenten vorgelegt bekomme, während ich bei Controller-basierten Frameworks a la Struts & Co. mir meine Ajaxfunktionalität selbst zusammenschustern muss. Für mich, der mit JavaScript wenig zu tun haben will, ein klarer Punkt zugunsten der Komponentenframeworks.

3.) Man sieht die URL nicht (richtig) bzw. kann keine Parameter anhängen.

Grundsätzlich ist diese Aussage richtig, da man meistens die vermeintliche Seite, von der man kommt, angezeigt bekommt. Dies kann man umgehen, indem man in den Navigationsregeln <redirect /> verwendet (gibt einige Besonderheiten, die man bei der Verwendung von redirect beachten muss, aber das darf jeder selbst nachschlagen). Die Problematik mit den Parametern stimmt und ist deshalb auch in der Spezifikation zu JSF 2.0 (JSR 314) adressiert. Was vermutlich mit suchmaschinenfreundlich gemeint ist, ist der Umstand dass JSF-Anwendungen oftmals aufgrund der fehlenden Parameter nicht "bookmarkable" waren und man daher nicht mitten in eine JSF-Anwendung einsteigen konnte. Wie gesagt, mit JSF wird hoffentlich alles besser. ^^

4.) Speicherhunger von Performance von JSF

Es stimmt, dass durch die höhere Abstraktion JSF langsamer ist als z. B. JSP oder Frameworks, die auf einer niedrigeren Abstraktionsschicht als JSF operieren. Die Benchmarks, die ich kenne (u. a. auch aus dem JavaMagazin, aber auch von diversen Websites) besagten bisher aber alle einen Geschwindigkeitsnachteil von JSF, der sich im Millisekundenbereich bewegte (http://it-republik.de/jaxenter/artikel/JSF-und-Struts-auf-dem-Leistungspruefstand-1327.html dürfte vermutlich der Artikel sein, der gemeint war). Ob dieser Geschwindigkeitsunterschied wirklich erfolgskritisch ist, muss von Situation zu Situation neu bewertet werden und kann nicht pauschal beantwortet werden. Dazu muss man sagen, dass heutzutage für viele Anwendungen die Performanz (die sich meist im Millisekundenbereich abspielt) eher sekundär ist, während Entwicklungsgeschwindigkeit und Wartbar- bzw. Erweiterbarkeit wesentlich wichtigere Erfolgsfaktoren für ein Projekt darstellen. Ähnlich verhält es sich mit dem Ressourcenhunger von JSF, für den man sich weniger Verwaltungsaufwand erkauft (wobei auch hier optimiert werden kann, wenn nicht alles in Beans aus dem Session- oder Application Scope abgelegt wird - hier wird übrigens mit JSF 2.0 der aus Spring bekannte Dialog Scope eingeführt, dürfte die Notwendigkeit für den Session Scope drastisch reduzieren). Jedoch dürfte dieser bei wenig frequentierten Websites kaum ins Gewicht fallen (zumal heute die Webserver eh schon einiges an Leistung und Speicher vorweisen können), während stark frequentierte Websites i. d. R. sowieso einiges an Hardware hintendran stehen haben (müssen), um Peaks zu überstehen. Ob auch dieser vermeintliche Nachteil sich als erfolgskritsich oder erfolgsfördernd herausstellen wird, muss wiederum von Situation zu Situation individuell bewertet werden.

5.) Ein komponentenbasiertes Modell bietet keine Unterstützung für weitere Dienste (z. B. WebServices).

Wie bereits von einem meiner Vorredner (eigentlich -schreiber ^^) angeführt, ist es auch gar nicht die Aufgabe eines Komponentenframeworks, Unterstützung für z. B. WebServices anzubieten. Ein gutes Softwaredesign zeichnet sich dadurch aus, dass eine strikte Trennung zwischen Geschäfts- und Präsentationslogik eingehalten wird. Zusätzliche Dienste wie bspw. WS setzen dabei bei der Geschäftslogik an und haben in der Präsentationsschicht nichts zu suchen (andernfalls nimmt man eine feste Verdrahtung mit der GUI in Kauf, was erfahrungsgemäß im Laufe eines Projektes zu erheblichen Mehraufwänden bei Entwicklung und Wartung führt). Ansonsten kann JSF als servletbasiertes Webframework in dieser Hinsicht nicht mehr oder weniger als andere servletbasierte Webanwendungen, egal ob diese nun controller- oder komponentenbasiert sind.

Sollten sich Fehler in meiner Darstellung eingeschlichen haben, wäre es nett, wenn ihr mir nen kleinen Tip geben könnt - man lernt ja schließlich gerne dazu  Ansonsten waren das jetzt 5 Kritikpunkte, zu denen ich kurz meine Sicht der Dinge darstellen wollte. Welches Framework man präferiert, muss jeder entsprechend der jeweiligen Ausgangssituation selbst entscheiden. Nur pauschal ein Framework als die Wunderwaffe vorzutragen (was meiner Meinung nach in diesem Forum viel zu oft geschieht), halte ich für wenig zielführend. Dafür ist die Ausgangslage einfach viel zu oft viel zu unterschiedlich.

So und jetzt seid ihr dran 

PS: Noch kurz zum Thema JSF. Ich persönlich erwarte von JSF 2.0 recht viel und bin sehr gespannt, ob es die auf der Spec-Seite angekündigten Veränderungen wirklich so realisieren wird, wie ich mir das erhoffe.


----------

