Diskussion:Struts

Kritik an der Kritik

Ich finde eine Kritik hat hier nix zu suchen, denn sowas lässt sich in jeden technischen Artikel einbauen. Das ist hier nicht Stiftung-Warentest. Der Link unten genügt. (Ausserdem sind die ersten beiden Kritikpunkt nicht ganz korrekt)

• Auf synchronisierung muss das backend achten - nicht das frontend (actions liegen im frontend)
• Das Actions keine Schnittstellen sondern abstrakte Klassen sind ist kein Nachteil sondern ein Feature - Struts stellt ein Basisframework dar, das jeder an seine Bedürfnisse anpassen soll (wieso daher unflexibel ?). D.h. Jeder erweitert erstmal die Action um eine anwendungsweite, anwendungsbezogene Action, von der jede weitere implementierte Action dann erbt - so ist das auch gedacht.
• Der 3. Punkt stimmt wohl aber man kann mit leben - Spring z.B. übertreibt es dabei. Matrixx (29.06.05)

Ich würde sogar sagen, dass man den dritten Punkt nicht im Raum stehen lassen kann, da jedes Framework von Haus aus mehr Overhead hat. Dass dies aber die Wartbarkeit eher vereinfacht, sieht man an größeren Applikationen, an denen auch mehrere Leute arbeiten. Durch die Standardisierung (wie bereits im Artikel erwähnt) kann man generell davon ausgehen, dass die Wartbarkeit vereinfacht wird. Bei sehr kleinen Applikation wird durch den anfänglichen Overhead auch von Struts abgeraten.--217.68.187.8 16:13, 24. Jul 2005 (CEST)

In dem Artikel waren bisher nur Vorteile von Struts beschrieben. Die Kritik deutet an, dass es auch Nachteile gibt. Dies ist im Sinne des neutralen Standpunktes notwendig, nicht im Sinne der Stiftung Warentest.

• Das Frontend muss insofern auf die Synchronisierung achten, als Actions keine eigenen Variablen hinzugefügt werden dürfen. Das ist riskant. Ob das nun ein schlimmes oder ein vernachlässigbares Risiko ist, sei dahingestellt.
• Eine bestimmte abstrakte Basisklasse vorzuschreiben, schränkt die Flexibilität ein, weil ich in der Basisklasse vorhandene Implementierungen nicht durch eigene ersetzen kann. Modernere Frameworks bieten häufig sowohl eine Schnittstelle, als auch eine abstrakte Klasse, als auch eine Default-Implementierung. Erich Gamma hat dazu viel geschrieben, ich stelle aber gerade fest, dass das in der Wikipedia noch fehlt. Muss ich mich wohl mal daran setzen.
• Natürlich erhöhen Frameworks den Overhead. Es geht aber darum, dass dieses Framework mich zwingt, Teile meiner fachlichen Konzepte doppelt zu implementieren, und das müsste nicht sein. Das ist dritte Kritikpunkt.

Übrigens folgt aus der Kritik nicht, dass man Struts nicht benutzen sollte. Es gibt wenige Alternativen und Struts hat den großen Vorteil, dass viele Programmierer sich damit auskennen. Also sollten die Struts-Fans etwas Kritik locker ertragen können, ohne sich angegriffen zu fühlen.  ;-) --jpp 17:03, 24. Jul 2005 (CEST)

Die Kritik sollte generell überarbeitet werden, mit Struts2 haben sich nämlich eine Punkte erübrigt. (nicht signierter Beitrag von 141.39.84.3 (Diskussion) )

Es steht dir frei, das zu tun. Sei mutig! --j ?! 20:35, 10. Jun. 2008 (CEST)

Ich war mutig und habe die Kritik kurzer Hand ganz entfernt, da bei näherer Betrachtung keiner der Punkte mehr auf Struts 2 zutrifft. Ein anderer Benutzer hat mir jedoch nicht geglaubt und die alte Version mit einer schnippischen Bemerkung wieder zurückgesetzt. Ich habe den Abschnitt nun wieder entfernt. Hier ein Link, der die Unterschiede zwischen Struts 1 und 2 aufzeigt: http://struts.apache.org/2.0.11.1/docs/comparing-struts-1-and-2.html mfg

Artikel teilweise unverständlich

Ich bin nicht in dem Bereich tätig, jedoch denke ich, dass der Artikel zu hart formuliert ist. Im Model-2 Bereich verstehe ich kaum etwas, es fehlen genauere Erläuterungen, ich fühle mich so, als ob ich der total Strutsfreak sein müsste, damit ich etwas verstehe. Kann man das nicht besser erklären? --Rafael Bugajewski 02:01, 27. Nov 2005 (CET)

Kann ich nur voll zustimmen. Man kann nicht erwarten, dass jemand, der sich diesen Artikel anschaut, eine technische Dokumentation sucht (was auch nicht Wikipedia-Sinn ist). Abgesehen davon zeugt der Artikel von einem wirklich schlechten Schreibstil und klingt zuweilen nach Babelfish.

Beispiel: "beim Submit der Form ..." - was spricht gegen "beim Abschicken des Formulars"? Daß im Java- und HTML-Code "Submit" auftaucht? Bezeichner korrekt zu benennen und einen Ablauf auf deutsch zu erklären sind zwei völlig verschiedene Dinge. -- 212.202.41.191 23:50, 23. Mai 2006 (CEST)

Genau dieses Unwohlsein, beim Versuch sie zu begreifen, spiegelt allerdings auch eines der Probleme, -vielleicht genau das fatale-, wider, das die Java-Web-Anwendungen mit sich gebracht haben... Ein Kosmos, dessen Regeln leider nicht mehr überwiegend aus Notwendigkeit, sondern der Forderung nach Konsens und dem Wunsch nach rückwirkender "Nützlichmachung" entstehen. Solche Komplexität in einfache Sprache zu fassen, sollte gar nicht so sehr versucht werden: Es isso. Feuern nach Belieben.

Sprache

Immer fein 'Modell' (mit doppeltem l) schreiben, wenn es nicht ein zusammengesetzter englischer Eigenname werden soll. -- TorstenS

Struts besitzt kein Modell ?

Merkwürdige Aussage, dass dem MVC-Framework Struts das M fehlen soll. Die ActionForms bilden das Modell ab. Die Aussage unter Aufbau ist daher falsch. --matrixx 11:21, 23. Jun. 2007 (CEST)

Link ungültig

Der Verweis zu "MVC#Modell 2" im Abschnitt "Model-2-Architektur mit Struts" führt zur Zeit ins Leere. --84.190.32.83 15:03, 21. Okt. 2009 (CEST)

WP:Sei mutig und bessere es einfach aus... --Sebastian.Dietrich 17:17, 21. Okt. 2009 (CEST)

Seite umbenennen

Der Artikel sollte in Struts 1 umbenannt werden. Alle Mechanismen, die hier beschrieben sind, beziehen sich auf Struts 1. Struts 2 ist ein vollständiges Redesign von Struts 1 und hat auch andere Mechanismen (keine FormBeans mehr), andere Konfigurationsdateien etc. -- ManfredWolff 13:36, 5. Apr. 2011 (CEST)

Grauenhafte Vermischung von Struts1 und Struts2

Der Abschnitt mit dem "Beispiel" aus Struts1 und 2 ist unlesbar. Im Struts1-Bsp steht was eMail, im Struts2-Bsp taucht das nicht auf, was dort passiert ist unklar. Konzentriert euch auf eine Verison (die neueste) oder trennt das klar ab, diese Vermischung mit Klammersätzen und inhaltlich verschiedenen Beispielen (eMail vs non-eMail) dient nicht gerade zum Verstädniss. Entweder separate Abschnitte wo die jeweilige Version behandelt wird oder Beispiele ganz weglassen.

Datum

Ich finds irritierend, dass im Infokasten als Erscheinungsjahr 2006 angegeben wird, während im Text angeben ist, dass 2004 zu Apache Top Level Projekt aufgestiegen ist. So steht es auch auf der Seite des dritten Links: 18 March 2004 - Jakarta Struts' graduation with honors into Apache Struts (nicht signierter Beitrag von 2A01:598:A00B:ADE:E08E:3FB4:B18A:3B32 (Diskussion) 09:39, 24. Jan. 2021 (CET))

Was ist daran irritierend? Zuerst ist Struts erschienen und erst später wurde es Top-Level Projekt. Das ist so bei allen Top-Level Projekten - zuerst im Incubator und dann erst Top-Level Projekt. --10:35, 24. Jan. 2021 (CET) (unvollständig signierter Beitrag von Sebastian.Dietrich (Diskussion | Beiträge) )

Laut dieser Wiki-Seite ist es doch genau umgekehrt! Es ist bereits 2004 zum Top Level Projekt aufgestiegen und erst 2006 soll es erschienen sein. Also ist es zum Top Level Projekt aufgestiegen bevor es erschienen ist? Wo kommt die 2006 überhaupt her? Im Text steht, dass es 2000 entwickelt wurde, aber wo die 2006 herkommt, ist schleierhaft. (nicht signierter Beitrag von 2A01:598:A00B:ADE:E08E:3FB4:B18A:3B32 (Diskussion) 12:00, 24. Jan. 2021 (CET))