Die ewige Suche nach dem richtigen Web-Framework

[deamon]

Hallo,

in der letzten Zeit habe ich versucht, mit Spring MVC eine Webanwendung zu entwickeln. Die Architektur und Flexibiliät von Spring MVC gefällt mir auch, aber trotzdem werde ich nicht so richtig warm mit diesem Framework. Immer wieder stehe ich vor Problemen und weiß nicht weiter, irgendwann habe ich bisher (bis auf das letzte Problem) immer eine Lösung gefunden, aber ich habe das Gefühl, dass ich mich mehr mit dem Framework als mit der eigentlichen Aufgabe befasse. So langsam reift bei mir die Erkenntnis, dass ich mit Spring MVC einfach nicht glücklich werde.

Die Frage ist nur: Was dann?

Folgende Anforderungen habe ich an ein Webframework:
* Bindung übergebener Daten an beliebige POJOs
* Validierung, anschließende Anzeige von Eingabefehlern sollte einfach sein
* Unterstützung für Internationalisierung
* URLs sollten weitgehend nach eigenem Geschmack auf Controller und Methoden abgebildet werden können. URLs sollten auch nach bestimmten Nutzeraktionen noch als Lesezeichen taugen.
* So wenig externe (XML-)Konfiguration wie möglich
* Unterstützung von Datei-Uploads
* Saubere Trennung von Programmlogik und HTML
* Erweiterbar
* Einfache Dinge sollten auch einfach umsetzbar sein.
* Framework sollte nicht fest an ein Build-System wie Maven gekoppelt sein.
* HTML-Seiten sollten ohne JSF und möglichst auch ohne JSP erzeugt werden können (FreeMarker gefällt mir besser).
* Erzeugte Seiten sollen prinzipiell auch ohne JavaScript funktionieren.
* Die Zukunft des Frameworks sollt einigermaßen gesichert sein.

Ich habe mich durch diverse Seiten im Web gewühlt und folgende Eindrücke von verschiedenen Frameworks gewonnen:

Spring MVC
----------
pro
* saubere Architektur
* Sehr flexibel und gut erweiterbar

kontra
* relativ viel Konfiguration
* Ich stehe immer wieder vor rätselhaften Problemen und werde mit dem Framework einfach nicht warm.


Wicket
------
pro
* HTML-Komponenten werden in Java gesteuert
* Mehr Web-Funktionen sind standardmäßig enthalten (Stichwort Hochladen von Dateien)
* keine Annotationen notwendig
* Pures Java, keine XML-Konfiguration
* Pure HTML-Vorlagen
kontra
* höherer Speicherbedarf, dadurch dass der Status der Anwendung je Nutzer gespeichert wird
* hoher Lernaufwand (http://entwickler.de/zonen/portale/psecom,id,101,online,1301,.html)
* hässliche URLs, die an eine Sitzung gebunden werden

Tapestry
--------
pro
* wahrscheinlich performanter als Wicket
kontra:
* soll komplexer/schwerer erlernbar als Wicket sein
* XML-lastig
* schlecht dokumentiert
* Schwer testbar, weil man teilweise zu abstrakten Klassen gezwungen wird. (http://www.infoq.com/news/2006/12/wicket-vs-springmvc-and-jsf)

Struts 2
--------
pro
* scheint relativ geradlinig zu sein, wenn man mal von der XML-Programmierung absieht.
kontra
* Umständliche Bindung der Parameter an Objekte
* XML-lastige Konfiguration
* Validierung in XML gefällt mir _überhaupt nicht_!
--> Struts scheint ein Beispiel für XML-Programmierung zu sein

JSF
---
pro
* Argumente dafür gibt es zwar auch, aber wegen folgender Gründe scheidet es trotzdem aus
kontra
* Ohne HTTP POST läuft praktisch nichts -> ein Unding!
* JavaScript verseucht bis in den letzten Zipfel
* Ressourcenhungrig
* Architektonische Schwächen
--> JSF kommt für mich nicht in Frage

JBoss Seam
----------
* Basiert auf JSF, kommt also auch nicht in Frage.

Stripes
--------
pro:
* einfache Bindung der Parameter an Objekte
* wenig Konfiguration
* soll relativ einfach zu erlernen sein
kontra:
* Die Action-Beans sehen denen von Struts verdächtig ähnlich. Da gefällt mir die Bindung der Parameter an ein POJO à la Spring besser.
* Projekt scheint relativ klein und wenig bekannt zu sein. Die Zukunft ist möglicherweise etwas unsicher.
* Validierung in den ActionBeans gefällt mir nicht. Nach meiner Meinung gehört das in die Domain-Klasse oder höchstens in eine Validatorklasse, die einer Domain-Klasse zugeordnet ist.

Alles in allem scheint mir Wicket die verlockendste Möglichkeit zu sein. Ich habe sehr viel Gutes und nur wenig Schlechtes darüber gelesen. Was mich allerdings sehr stört sind die hässlichen URLs. Das ist nun mal ein wesentlicher Teil der Außenansicht der Anwendung. Aber vielleicht könnte ich damit leben.

Welche Framework könnt ihr mir empfehlen und welches von den genannten passt am besten zu meinen Anforderungen?

 

[huhny]

Hm, ist es wichtig das es auf Java basiert? Wenn nicht, dann schau Dir doch mal Ruby on Rails oder Groovy on Rails (um in der JVM zu bleiben) an. Rails dürfte allen Deinen Ansprüchen gerecht werden.

 

[Gelöschtes Mitglied 5909]

http://grails.org/

schau dir das mal an

 

[Gelöschtes Mitglied 6946]

Bei Wicket kann man mittels URL-Mounting auch hübsche URLs erzeugen. Gibt da verschiedene URL-Coding-Strategies und man kann auch eigene basteln, so dass man bis zu einem gewissen Punkt eine gute Kontrolle über das Aussehen der URLs hat. Allerdings hat man keine 100%ige Kontrolle, wie es bei Action-orientierten Frameworks der Fall ist - jedenfalls würde ich diesen Contra-Punkt etwas abschwächen wollen

Seam selber kann man glaub ich auch unabhängig von JSF einsetzen - gibt glaub ich sogar ne Integration in Wicket für dat Ding.

 

[disaster]

Hallo, nutze jetzt seit kurze Zeit Struts 2, habe jetzt aber leider keine Zeit viel zu schreiben. Ich werde mal gucken, ob ich das heute Abend schaffe. Vorab kann ich dir schonmal sagen, dass mir Struts 2 bislang recht gut gefällt und nicht alle Punkte deiner Kontro-Liste unbedingt so stimmen.

Vielleicht kannst du nochmal sagen, was du hiermit genau meinst:

* Umständliche Bindung der Parameter an Objekte

 

[deamon]

Vielleicht kannst du nochmal sagen, was du hiermit genau meinst:

* Umständliche Bindung der Parameter an Objekte

In Spring MVC gibt man im Controller einfach ein POJO an und Spring bindet die übergebenen Parameter daran. Sowie ich das bei Struts gesehen habe, muss man im Controller (oder war es "Command Bean"?) für jeden Parameter eine Set-Methode definieren.

 

[disaster]

Ok, dann versuch ich mal ein bisschen was zu schreiben, in der Hoffnung dir weiterhelfen zu können. Zuerst einmal muss ich sagen, dass ich mich selbst erst ein paar Wochen mit Struts 2 beschäftige und insofern nicht alles ohne Zweifel beantworten kann.

* Bindung übergebener Daten an beliebige POJOs

Wie du schon gesagt hast, läuft das im Falle von Struts2 über entsprechende Setter-Methoden, die standardmäßig über ihren Namen definieren, was "injected" werden soll. Dadurch dass der Typ beim Paramter angegeben ist, kann Struts 2 integrierte oder manuell erstellte Converter benutzen um Strings (was anderes bekommt man ja über das text-basierte HTTP nicht) in den gewünschten Typ umzuwandeln.

Ansonsten gibt es ein Spring-Plugin mit dem man Struts 2 und Spiring problemlos verbinden und somit auch die Dependency Injection und alle Typen des Autowiring nutzen kann. Auch die "Constructor Injection" ...

Womöglich vermisch ich hier gerade zwei Sachen, leider hab ich Spring in Kombination mit Struts 2 bis jetzt nicht genutzt, sondern nur davon gelesen und ich weiß nicht genau, wie Spring, sodass mir das Vergleichen etwas schwer fällt.


* Validierung, anschließende Anzeige von Eingabefehlern sollte einfach sein

Ist in Struts 2 wirklich einfach. Es gibt mehrere Wege die Validierung umzusetzen. Zuerst einmal gibt es einige vorgefertigte Validator (Überprüfung auf leeres Feld, Maximal-/Minimal-Angaben bei Zahlenwerte, Textlänge, Email-/URL-Validator, Regexp, ...). Entsprechende Fehlermeldungen werden direkt mit angegeben, wie du wahrscheinlich schon gesehen hast.
Sollten die bereits vorhanden Validator nicht ausreichen gibt es zwei weitere Möglichkeiten:
1. Für den Fall, dass du die gewünschte Validierung noch häufiger brauchen wirst, schreibt man einen eigenen Validator, was durch vorgefertigte abstrakte Klassen, die Struts 2 mitliefert völlig problemlos ist.
2. Ist vorrauszusehen, dass du die Validierung nur einmal brauchen wirst, besteht die Möglichkeit die Validierung direkt in der gewünschten Action vorzunehmen. Bei Implementierung der ActionSupport-Klasse (die man grundsätzlich importieren sollte, um sich die Arbeit zu erleichtern, ABER natürlich nicht muss (!), Actions dürfen auch simple POJOs sein) wird nur eine Methode validate() benötigt, in der die Validierung stattfindet. Das Aufrufen dieser Methode vor Ausführen der Action übernimmt Struts 2.

Du hast oben bemängelt, dass dir die Validierung per XML überhaupt nicht gefällt, was ich nachvollziehen kann, weil es mir genauso ging / geht. Die gesamte Validierung lässt sich in Struts 2 mittlerweile aber auch komplett ohne XML lösen. Für alle Validator stehen entsprechende Annotations zur Verfügung, über die die selbe Funktionalität erreicht werden kann.
Was ich allerdings dazu sagen muss, ist, dass ich mich bislang noch nicht damit beschäftigt habe, wie per Annotation ein eigener Validator genutzt werden kann, da ich mich damit noch nicht beschäftigen musste. Bisher kam ich mit den Built-In-Validatorn, komplett ohne XML, gut aus.


* Unterstützung für Internationalisierung

Sollte mit Struts 2 ebenfalls kein Problem sein. Struts 2 nutz die beiden Java-Klassen ResourceBundle und Locale und stellt zusätzliche Methoden und Tags bereit um die Texte in den Actions und per Struts 2 Tag in der View auszugeben. Mir fällt jetzt nicht viel ein, was ich hier schreiben könnte, weils einfach nicht viel zu schreiben gibt, aber wenn du irgendwas wissen möchtest, frag ruhig.


* URLs sollten weitgehend nach eigenem Geschmack auf Controller und Methoden abgebildet werden können. URLs sollten auch nach bestimmten Nutzeraktionen noch als Lesezeichen taugen.

Daduch das Struts 2 actionbasiert ist, kannst du eigentlich ohne Einschränkungen selbst bestimmen wie die URL für jede Seite / Aktion aussehen soll. Standardmäßig haben Actions in Struts2 die Endung .action, aber diese Endung ist frei wählbar und kann soweit ich weiß auch komplett weggelassen werden, wenn dir das besser gefällt.


* So wenig externe (XML-)Konfiguration wie möglich

Dass die von dir bemängelte XML-Validierung gar nicht nötig ist, habe ich ja oben schon geschrieben. Letztendlich wirst du um ein wenig XML-Konfiguration allerdings nicht rumkommen. Zumindest die struts.xml für das Action-Mapping brauchst du noch (so wie ich das gelesen habe, versuchen die Struts 2-Entwickler ebenfalls in der Zukunft immer mehr von der XML-Konfiguraton wegzukommen oder zumindest Alternativen (wie es im Fall der Validierung ja schon passiert ist). Abgesehen von der struts.xml habe ich bisher wenig per XML konfigurieren müssen...


* Unterstützung von Datei-Uploads

In Struts 2 integriert. Kann ich jetzt nicht so viel zu sagen Ist aber kein Problem. Falls du Fragen hast, frag.


* Saubere Trennung von Programmlogik und HTML

Ist ebenfalls gegeben.. Logik in den Actions, View (HTML) über JPS, Freemarker- oder Velocity-Templates..


* Erweiterbar

Soweit ich weiß legen auch da die Entwickler von Struts 2 sehr viel wert drauf und unterstützen das Erweitern und Entwickeln von allen möglichen Struts2-Komponenten: eigene Interceptor, Converter, Validator, Results, Plugins sowie eigene Tags, Templates und Themes für den "View-Part" und wahrscheinlich alles wa sich vergessen habe


* Einfache Dinge sollten auch einfach umsetzbar sein.

Fällt mir jetzt schwer drauf zu antworten, da meine Phantasie nicht ausreicht um mir selbst ein konkretes Beispiel auszudenken


* Framework sollte nicht fest an ein Build-System wie Maven gekoppelt sein.

Ist bei Struts 2 nicht der Fall... Ich benutze im Moment nur Eclipse + WTP


* HTML-Seiten sollten ohne JSF und möglichst auch ohne JSP erzeugt werden können (FreeMarker gefällt mir besser).

Wie oben schon angedeutet. JSP, Freemarker und Velocity werden von Haus aus unterstützt. (Intern benutzt Struts 2 ebenfalls Freemarker)


* Erzeugte Seiten sollen prinzipiell auch ohne JavaScript funktionieren.

Lege ich auch Wert dauf, liegt aber prinzipiell in dern Hand des Entwicklers. Struts 2 bringt beispielsweise einige AJAX-Komponenten mit, die aber selbstverständlich nicht benutzt werden müssen. Die Validierung kann teilweise auch schon vorab per JavaScript geschehen, ohne dass die Seite neu geladen werden muss, ist aber ebenfalls optional.

Letztendlich sollte sich dein Wunsch auf jeden Fall einrichten lassen.


* Die Zukunft des Frameworks sollt einigermaßen gesichert sein.

Kann ich jetzt nicht viel zu sagen, zumindest wird es aktiv weiterentwickelt Was mich ein bisschen erschrocken oder enttäuscht hat, war dass die Community (zumindest im Moment noch) relativ klein zu sein scheint, was mich ein bisschen stört, da man doch nicht so schnell Hilfe erhält wie vielleicht bei Struts 1 oder JSF... Ich hoffe das ändert sich noch.



Das wars erstmal von mir. Wie gesagt, ich bin selbst erst vor Kurzem angefangen und kann noch nicht all zu viel sagen, aber mittlerweile bin ich doch recht zufrieden. Ich hab in den letzten Tagen das Buch Struts 2 In Action gelesen, was mich sehr weiter gebracht hat. In jedem Fall empfehlenswert.

Ob Struts 2 das richtige Framework für dich ist, musst du natürlich nach wie vor selbst entscheiden und ich möchte mir auch nicht anmaßen, selbst irgendwelche Urteile zu fällen, da ich bislang einfach keines der anderen getestet habe, abgesehen von Tapestry. Das zwar auf den ersten Blick sehr nett aussieht, nach einigen Tagen aber auch immer mehr Fragen aufgeworfen hat. Letztendlich schien es mir noch nicht 100%ig ausgereift.

Bei weiteren Fragen, versuche ich gerne weiterzuhelfen.

 

[disaster]

Noch eine Sache... Was das Action-/Result-Mapping angeht, habe ich mich geirrt.. auch das ließe sich in Struts 2 über Annotations und Conventions lösen. Ist für mich persönlich aber nichts.

 

[deamon]

Hallo disaster,

vielen Dank für deine ausführliche Antwort!

Die Bindung von Formulardaten über Setter-Methoden im Controller gefällt mir nicht so richtig. Das führt doch letztlich nur dazu, dass man Methoden von Domain-Objekten im Controller wiederholt.

Nehmen wir mal folgendes Beispiel aus dem Struts-Tutorial:

package tutorial;
import com.opensymphony.xwork2.ActionSupport;
public class Logon extends ActionSupport {

    public String execute() throws Exception {
        if (isInvalid(getUsername())) return INPUT;
        if (isInvalid(getPassword())) return INPUT;
        return SUCCESS;
    }

    private boolean isInvalid(String value) {
        return (value == null || value.length() == 0);
    }

    private String username;
    public String getUsername() {
        return username;
    }
    public void setUsername(String username) {
        this.username = username;
    }

    private String password;
    public String getPassword() {
        return password;
    }
    public void setPassword(String password) {
        this.password = password;
    }

}

Hier wird kein Domain-Objekt (user) verwendet, weil die übergebenen Daten nach dem Login weggeworfen werden können, aber würde hier z. B. eine Adresse eingegeben, die auch mal gespeichert werden soll, müsste man Methoden des Domain-Objekts im Controller wiederholen. Etwa so:

public class Address extends ActionSupport {

		private Adresse adress = new Adress();
		private Repository repository; // würde injiziert

    public String execute() throws Exception {
    	repository.save(adress);
    }

    public void setStreet(String street) {
        adress.setStreet(street);
    }
}

Die Setter, die "address" eh schon hat, werden hier also wiederholt. Man könnte natürlich auch dieses Objekt als Domain-Objekt verwenden, aber das wäre eine Software-Architektur-Sünde, denn damit würde Struts in das gesamte fachliche Modell sickern.

Vergleich das mal mit Spring MVC:

public class AddressController extends AbstractCommandController{
	private Repository repository; // würde injiziert
	public ModelAndView handle(HttpServletRequest request, HttpServletResponse response, HttpSession session, Address address){
		repository.save(address);
          return new ModelAndView("adresspage", address);
	}
}

Hier werden die vom Browser gesendeten Parameter an die vorhandene Domain-Klasse Adress übergeben. Das finde ich viel klarer.

An Struts stört mich auch, dass man den Programmablauf teilweise in XML beschreibt! Es gibt meiner Meinung nach keinen vernfünftigen Grund, diesen zentralen Aspekt eines Programms extern zu konfigurieren.

Genauso unschön finde ich Validierung in XML, auch Validierung halte ich für einen zentralen Aspekt eines Programms. Validierung gehört nicht nur in das Programm selbst, sondern meiner Meinung direkt in das zu prüfende Objekt, denn das sollte verantwortlich für seinen Zustand sein, sonst ist es nämlich nicht viel mehr als eine aufgeblasene, dumme Datenstruktur. Aber du schreibst ja, dass es mittlerweile auch über Annotationen geht, was sicher eine Verbesserung ist. Schön wäre noch, wenn es endlich einen Standard für Validierung gäbe und man sein Projekt nicht von einem bestimmten Implementierung abhängig machen müsste.

Was mich ein bisschen erschrocken oder enttäuscht hat, war dass die Community (zumindest im Moment noch) relativ klein zu sein scheint

Ich habe irgendwie das Gefühl, dass der Stern von Struts sinkt. JSF wurde als Struts-Nachfolger vorgestellt und scheint ziemlich erfolgreich zu sein - und ziemlich hässlich. Neben Struts gibt es aber noch eine ganze Reihe anderer Frameworks, die um die Gunst der Entwickler buhlen. Bei Struts 1 war das noch nicht so, was wohl zu dem großen Erfolg beigetragen hat.

Auch wenn sich Struts bis auf meine erwähnten Kritikpunkte ganz ordentlich anhört, begeistert es mich nicht so richtig.

Bei den ganzen monströsen Frameworks war es eine richtige Erfrischung auf WEB4J zu stoßen. Das ist sozusagen ein KISS-Framework, das mal nicht mit dem Strom schwimmt und gängige Praktiken in der Java-Welt kritisch hinterfragt. Selbst wenn man es nicht einsetzen möchte, ist es interessant die gut dokumentierten Konzepte zu lesen.

Mittlerweile überlege ich ernsthaft, mir selbst ein kleines Framework zu schreiben.

 

[disaster]

Hallo disaster,

vielen Dank für deine ausführliche Antwort!

Die Bindung von Formulardaten über Setter-Methoden im Controller gefällt mir nicht so richtig. Das führt doch letztlich nur dazu, dass man Methoden von Domain-Objekten im Controller wiederholt.

Nehmen wir mal folgendes Beispiel aus dem Struts-Tutorial:

package tutorial;
import com.opensymphony.xwork2.ActionSupport;
public class Logon extends ActionSupport {

    public String execute() throws Exception {
        if (isInvalid(getUsername())) return INPUT;
        if (isInvalid(getPassword())) return INPUT;
        return SUCCESS;
    }

    private boolean isInvalid(String value) {
        return (value == null || value.length() == 0);
    }

    private String username;
    public String getUsername() {
        return username;
    }
    public void setUsername(String username) {
        this.username = username;
    }

    private String password;
    public String getPassword() {
        return password;
    }
    public void setPassword(String password) {
        this.password = password;
    }

}

Hier wird kein Domain-Objekt (user) verwendet, weil die übergebenen Daten nach dem Login weggeworfen werden können, aber würde hier z. B. eine Adresse eingegeben, die auch mal gespeichert werden soll, müsste man Methoden des Domain-Objekts im Controller wiederholen. Etwa so:

public class Address extends ActionSupport {

		private Adresse adress = new Adress();
		private Repository repository; // würde injiziert

    public String execute() throws Exception {
    	repository.save(adress);
    }

    public void setStreet(String street) {
        adress.setStreet(street);
    }
}

Die Setter, die "address" eh schon hat, werden hier also wiederholt. Man könnte natürlich auch dieses Objekt als Domain-Objekt verwenden, aber das wäre eine Software-Architektur-Sünde, denn damit würde Struts in das gesamte fachliche Modell sickern.

Vergleich das mal mit Spring MVC:

public class AddressController extends AbstractCommandController{
	private Repository repository; // würde injiziert
	public ModelAndView handle(HttpServletRequest request, HttpServletResponse response, HttpSession session, Address address){
		repository.save(address);
          return new ModelAndView("adresspage", address);
	}
}

Hier werden die vom Browser gesendeten Parameter an die vorhandene Domain-Klasse Adress übergeben. Das finde ich viel klarer.

An Struts stört mich auch, dass man den Programmablauf teilweise in XML beschreibt! Es gibt meiner Meinung nach keinen vernfünftigen Grund, diesen zentralen Aspekt eines Programms extern zu konfigurieren.

Genauso unschön finde ich Validierung in XML, auch Validierung halte ich für einen zentralen Aspekt eines Programms. Validierung gehört nicht nur in das Programm selbst, sondern meiner Meinung direkt in das zu prüfende Objekt, denn das sollte verantwortlich für seinen Zustand sein, sonst ist es nämlich nicht viel mehr als eine aufgeblasene, dumme Datenstruktur. Aber du schreibst ja, dass es mittlerweile auch über Annotationen geht, was sicher eine Verbesserung ist. Schön wäre noch, wenn es endlich einen Standard für Validierung gäbe und man sein Projekt nicht von einem bestimmten Implementierung abhängig machen müsste.

Was mich ein bisschen erschrocken oder enttäuscht hat, war dass die Community (zumindest im Moment noch) relativ klein zu sein scheint

Ich habe irgendwie das Gefühl, dass der Stern von Struts sinkt. JSF wurde als Struts-Nachfolger vorgestellt und scheint ziemlich erfolgreich zu sein - und ziemlich hässlich. Neben Struts gibt es aber noch eine ganze Reihe anderer Frameworks, die um die Gunst der Entwickler buhlen. Bei Struts 1 war das noch nicht so, was wohl zu dem großen Erfolg beigetragen hat.

Auch wenn sich Struts bis auf meine erwähnten Kritikpunkte ganz ordentlich anhört, begeistert es mich nicht so richtig.

Bei den ganzen monströsen Frameworks war es eine richtige Erfrischung auf WEB4J zu stoßen. Das ist sozusagen ein KISS-Framework, das mal nicht mit dem Strom schwimmt und gängige Praktiken in der Java-Welt kritisch hinterfragt. Selbst wenn man es nicht einsetzen möchte, ist es interessant die gut dokumentierten Konzepte zu lesen.

Mittlerweile überlege ich ernsthaft, mir selbst ein kleines Framework zu schreiben.

Dafür gibt es in Struts 2 die Möglichkeit die Actions als "ModelDriven" zu deklarieren. Das würde dann folgendermaßen aussehen und zu genau dem führen, was du haben möchtest:

public class Address extends ActionSupport implements ModelDriven{

		private Adresse adress = new Adresse();
		private Repository repository; // würde injiziert  // Man kann wie gesagt mit relativ wenig Arbeit (dem Spring-Plugin) die Dependency Injection von Spring nutzen

    public String execute() throws Exception {
    	repository.save(adress);
    }

    public void getModel() {
                return adress;
    }
}

Vom schreiberischen Aufwand her natürlich genauso viel, aber wenigstens sauberer und wahrscheinlich eher das was du wolltest.
Ich will aber auch gar nichts schönreden Selbstverständlich hat Struts 2 auch seine Nachteile, wie sie ja leider alle Frameworks haben, wie du schon festsellen musstest Letztendlich bin ich wahrscheinlich auch der falsche Ansprechpartner, denn so viel Ahnung hab ich jetzt nicht. Ich habe erst vor ~4einhalb Monaten mit Java und vielleicht vor 3 oder 4 Wochen mit der Web-Entwicklung angefangen und habe dementsprechend wenig Erfahrung, mit der ich dir weiterhelfen könnte.

Schöne Grüße,
Christian

 

[disaster]

Ah.. entschuldigt bitte, ich wollte
1. nicht alles zitieren
und 2. die Seite nicht so in die Breite ziehen..


Hätte ich mich mal vorher angemeldet, könnte ich das jetzt editieren ;(

 

[Guest]

Struts 2
--------
* XML-lastige Konfiguration
* Validierung in XML gefällt mir _überhaupt nicht_!
--> Struts scheint ein Beispiel für XML-Programmierung zu sein

Ich habe in meinem Struts2-Projekt nicht eine XML-Datei. Kann man auch alles über Annotations machen.

 

[ps]

Tapestry
--------
pro
* wahrscheinlich performanter als Wicket
kontra:
* soll komplexer/schwerer erlernbar als Wicket sein
* XML-lastig
* schlecht dokumentiert
* Schwer testbar, weil man teilweise zu abstrakten Klassen gezwungen wird. (http://www.infoq.com/news/2006/12/wicket-vs-springmvc-and-jsf)

Ich muss dich korrigieren, ich habe mir vor einiger Zeit sowohl Tapestry als auch Wicket angesehen (JSF halte ich für einen großen Haufen Mist ).

Tapestry ist um einiges geradliniger als Wicket und viel performanter, da dies eines der Ziele bei der Entwicklung war.
Tapestry 5 kommt ohne auch nur eine Zeite XML aus - es läuft so gut wie alles über Configuration by Convention oder Annotationen. XML war nur bei Tapestry 4 notwendig.

Riskiere doch nochmal einen genauen Blick und gehe vielleicht das Tutorial auf der Seite durch (ca. 15 Minuten)... da bekommt man schon einen sehr guten Überblick. ( http://tapestry.apache.org ).

Struts 2
--------
pro
* scheint relativ geradlinig zu sein, wenn man mal von der XML-Programmierung absieht.
kontra
* Umständliche Bindung der Parameter an Objekte
* XML-lastige Konfiguration
* Validierung in XML gefällt mir _überhaupt nicht_!
--> Struts scheint ein Beispiel für XML-Programmierung zu sein

Auch hier muss ich dich berichtigen. Struts 2.1.x besitzt ein Modul Namens "Convention". Früher (2.0.x) war dies "ZeroConfiguration" und "Codebehind". Man kommt zwar nicht ganz ohne Configdatei aus, aber neue Seiten und dergleichen wird auch per Configuratoin by Convention gelöst: http://cwiki.apache.org/S2PLUGINS/convention-plugin.html

Struts2 ist also keinesfalls mehr XML lastig.. Die Option freilich hat man weiterhin, um komplexe Usecases abzubilden. Aber in 99,9% der Fälle sollte das mit den Konventionen funktionieren. Zb. gibt es auch ein REST Plugin mit welchem man in einem ähnlichen Stil wie in Ruby on Rails entwickeln kann.

 

[Audio Anarchy]

Wenn es nicht unbedingt ein Java Framework sein soll, warum kein PHP-Framework ala CakePHP oder Symfony wählen?

 

[ps]

Wenn es nicht unbedingt ein Java Framework sein soll, warum kein PHP-Framework ala CakePHP oder Symfony wählen?

Wenn es nicht Java sein muss könnte man auch Seaside (Smalltalk) oder Lift (Scala) in Betracht ziehen ^^

 

[deamon]

Wicket und Tapestry sehen schon interessant aus. An Wicket gefällt mir die Ähnlichkeit mit Swing und dass man programmiert und nicht mit Annotations deklariert. Irgendwie scheint klassische Programmierung aus der Mode gekommen zu sein; erst kam die Deklaration per XML und nun Annotations. Von daher gefällt mir der Ansatz von Wicket schon. Aber mir scheint es so, als müsste man ziemlich viel Code schreiben. Und irgendwo habe ich gelesen, dass man seine Klassenstruktur und die HTML-Vorlage ständig im Einklang halten müsste, während das bei Tapestry einfacher sein soll.

Das und der kürzere Quelltext sprächen also eher für Tapestry. Performanter scheint es auch zu sein und die Fehlermeldungen sehen auch 1a aus. Der dynamische Klassenlader hört sich auch gut an. Alles in allem macht mir Tapestry den besseren Eindruck.

Aber bei beiden Frameworks scheinen hässliche URLs Standard zu sein. Wie sind denn eure Erfahrung, den Frameworks zu schönen URLs zu verhelfen? Ich möchte nicht zwei URLs zu einem Ziel haben - einmal schön zum Lesezeichnen und einmal hässlich im Normalbetrieb. Ich hätte die URLs immer gerne in einer klaren und möglichst kurzen Form.

Und wie sieht es bei den beiden Frameworks mit JavaScript aus? Kann man die auch ohne vernünftig benutzen? (Also nicht so ein Mist wie bei JSF!)

Gruß
Christian

 

[rico]

Hi,

vielleicht hilft dir das hier weiter.

-> wiki.apache.org/tapestry/FriendlyUrls

Gruß
Rico

 

[Gelöschtes Mitglied 6946]

Wie ich bereits schrieb, kann man auch mit Wicket "schöne" URLs bauen, indem man eine der verschiedenen URL Coding Strategies nutzt oder eine eigene entwickelt. In der init-Methode der Application macht man dann z.B. sowas:

mount(new IndexedParamUrlCodingStrategy("/path", MyWebPage.class));

und schon sehen die URLs zu eben jener MyWebPage so aus:
www.example.com/path/param1/param2/

 

[Sempah]

In Spring MVC gibt man im Controller einfach ein POJO an und Spring bindet die übergebenen Parameter daran. Sowie ich das bei Struts gesehen habe, muss man im Controller (oder war es "Command Bean"?) für jeden Parameter eine Set-Methode definieren.

Wie ist es denn in Spring möglich mehrere "POJOs" vom Controller an die View zu übergeben? Also mit Struts klar durch die getter-Methoden, aber wie mit Spring?

 

[mschwarz]

Hallo,

ich habe mir auch immer die Frage gestellt, wohin die ganzen Aufwände verschwinden. Immerhin will ich mich um die Business-Logik und nicht um das Framework kümmern. Dann bin ich jedoch auf "Sombrero" gestoßen und dort geblieben. Hat den Nachteil, dass es erst gestern offiziell im Internet veröffentlicht wurde (http://www.sombrerosoft.de/). Deshalb findet man noch nichts in den Suchmaschinen. Trifft aber genau das, was ich immer gesucht habe.

 

[byte]

Sieht ja grausam aus. Eigenwerbung?

 

[Noctarius]

Sieht ja grausam aus. Eigenwerbung?

Vermutlich, aber sieht echt grausam aus das GUI. Sowas kann man nem Kunden nicht antun (zumind. würd ich's ned)

 

[mschwarz]

Ich weiß auch nicht, wie man Struts und Spring miteinander vergleichen kann. Die Struts-GUI's sind wirklich schlecht und das im Jahr 2009.

 

[Sempah]

Kennt zufällig jmd BO (WebI) und kann sagen womit diese GUI erstellt wurden ist?
Ist eine WebbApp, die wie eine Desktop App aussieht.

 

[Noctarius]

Hast du eine Adresse? Könnte vieles sein, GWT, ExtJS, RAP, usw

 

[byte]

Ich weiß auch nicht, wie man Struts und Spring miteinander vergleichen kann. Die Struts-GUI's sind wirklich schlecht und das im Jahr 2009.

Struts 1 ist uralt, längst nicht mehr State of the Art und ist nur noch aus historischen Gründen weit verbreitet. Struts 2 ist nicht wirklich der Bringer. Spring MVC schon eher, und das ist durchaus vergleichbar mit Struts (kA also wovon Du da redest).

 

[Sempah]

Hast du eine Adresse? Könnte vieles sein, GWT, ExtJS, RAP, usw

https://www.sdn.sap.com/irj/scn/go/...ary/uuid/e058e44e-9497-2b10-f9b8-aab169b017a2

-> Seite 27. Da kann man die GUI gut erkennen.

 

[HLX]

Ist vermutlich nicht GWT oder ExtJS. Es gibt noch zahlreiche andere AJAX-Frameworks. Hast du die Anwendung vorliegen? Dann könnte man es an den Dateien (z.B. JARs) im Web-Projekt erkennen.

Sieht ja grausam aus. Eigenwerbung?

Mir reichen schon die sog. Lizenzbedingungen. :noe:

 

[Noctarius]

SAP Zeugs wird in RAP (Rich Ajax Platform) sein. Das ist eine Ajax Implementierung des Eclipse RCP.

 

[Sempah]

Achso, vielen Dank

 

[homer65]

Hallo,

in der letzten Zeit habe ich versucht, mit Spring MVC eine Webanwendung zu entwickeln. Die Architektur und Flexibiliät von Spring MVC gefällt mir auch, aber trotzdem werde ich nicht so richtig warm mit diesem Framework. Immer wieder stehe ich vor Problemen und weiß nicht weiter, irgendwann habe ich bisher (bis auf das letzte Problem) immer eine Lösung gefunden, aber ich habe das Gefühl, dass ich mich mehr mit dem Framework als mit der eigentlichen Aufgabe befasse. So langsam reift bei mir die Erkenntnis, dass ich mit Spring MVC einfach nicht glücklich werde.

Das man bei der ersten Anwendung mit einem neuen Framework in Schwierigkeiten gerät ist wohl normal.
Sowas erfordert Zeit und Übung.
Aber ich glaube das es dir bei keinem anderen Framework besser geht.
Vielleicht solltest du nicht so schnell aufgeben.

 

[Unregistriert]

Hallo daemon,

ähnliche Anforderungen haben wir auch immer wieder (ist wohl fast immer so). JavaScript-freie Seiten sind aber kaum noch möglich, wenn die Formulare möglichst dynamisch sein sollen und nicht für jede Aktion die Seite neu geladen werden soll. Da wir unsere Formulare auch noch anhand veränderlicher Datenstrukturen generieren müssen, sind wir mit den gefunden Frameworks nicht glücklich geworden und haben vor ein paar Jahren begonnen, ein eigenes Framework zu entwickeln. Inzwischen ist es soweit gediehen, dass wir es öffentlich machen wollen, aber noch nicht genau wissen, in welcher Form wir das Framework herausgeben wollen. Für einen Blick auf die Features siehe FormEngine .

viele Grüße
Udo Stark

 

[JanHH]

Seam "basiert" nicht auf JSF, sondern vielmehr JSF mit diversen anderen Frameworks. Ansonsten vergleichst Du da auch Äpfel mit Birnen, weil die meisten erwähnten Frameworks nur fürs view-Frontend sind, während seam die ganze Spanne von View bis hin zur Persistenz abdeckt. Es leidet auch nicht unter den erwähnten JSF-Schwächen, sondern behebt diese vielmehr.

Gerade die Art, wie seam alles integriert, also JSF-Views, Beans für Persistenz und Applikationslogik, und die automatische Verwaltung des Persistenzkontext (JPA) macht es zu einer sehr eleganten, angenehmen Lösung. Ich würde dringend mal einen näheren Blick drauf empfehlen.

 

[Fireball29]

Wie ist denn hier der aktuelle Stand der Diskussion? Gibt es noch neue Erkenntnisse? Ich persönlich finde Spring 3 MVC schon super. Ich fand aber auch Struts2 nicht schlecht. Lift ist ein heisse Kandidat und Seam könnte den EJB Bereich endlich mal einfacher machen ;-)

Grüße Fireball

 

[anoneemous]

Hallo zusammen,

einen Blick wert ist meiner Meinung nach auch: playframework.org

Scheint noch relativ neu zu sein (und ich hab es auch noch nicht erschöpfend ausprobiert)
aber das Tutorial durchzuackern hat schon Spaß gemacht. Als Kurzbeschreibung könnte
man sagen das es sowas wie Ruby on Rails nur mit Java ist.