Diskussion:Struts

aus Wikipedia, der freien Enzyklopädie

[Bearbeiten] 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)

[Bearbeiten] 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.

[Bearbeiten] Sprache

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