Diskussion:Jakarta Server Pages

message: Hallo,
ich möchte den Autor in einer Kleinigkeit korrigieren:
Es ist falsch zu schreiben "JavaServer Pages werden ... umgewandelt." - Korrekt ist der Satz "JavaServer-Pages-Seiten werden ... umgewandelt." oder "JSP-Seiten werden ... umgewandelt".
Nachzulesen ist dies in dem tollen Buch "JavaServer Pages für Dummies" von Sahin Türeyenler.
Dort heisst es (wenn ich den Autor zitieren darf):
"Nomen est Omen
Die Bezeichnung dieser Technologie sorgt für einige Verwirrung. Da ich anfänglich selber in ein paar Fettnäpfchen getreten bin, möchte ich Ihnen dies ersparen. Die nachfolgenden "Richtlinien" sollten Ihnen helfen, immer die richtige Bezeichnung parat zu haben:
*Der Name JavaServer Pages ist äquivalent zu der Abkürzung JSP. Beides sind geschützte Markennamen.
*Achten Sie auf Leerzeichen! Die Bezeichnung Java Server Pages ist nicht korrekt.
*Verwenden Sie den Ausdruck JavaServer Pages nicht für eine Seite, eine Datei oder ein Dokument.
*Verwenden Sie den Ausdruck JSP nicht für eine Seite, eine Datei oder ein Dokument.
*Den Ausdruck JSPs für mehrere Seiten, Dateien oder Dokumente zu benutzen ist nicht korrekt.
*Verwenden Sie stattdessen die Ausdrücke JSP-Seite(n) oder JSP-Datei(en).
*So komisch es auch klingt, natürlich können Sie auch den Ausdruck JavaServer-Pages-Seite(n) benutzen."
Karsten Kaunat, 01.11.2004
(Der vorstehende Beitrag stammt von Karsten Kaunat (Beiträge) – 21:46, 2. Nov. 2004 (MEZ)
replies: text: wäre möglicherweise im Artikel auch praktisch - vielleicht ein Kapitel Namensgebung oder so.--Slartidan 14:53, 24. Feb 2006 (CET)
thread_title:  JavaServer Pages für Dummies 

message: EL expression exsitieren nicht erst seit JSP 2.0 die gab es scohn auch davor!!!
(Der vorstehende Beitrag stammt von 77.5.88.49 – 18:11, 16. Apr. 2007 (MESZ)
thread_title:  Expression Language 

message: Nach meiner Auffassung ist der Tag ein Siebtel der Woche; wenn es um Auszeichnungssprachen geht, ist es das Tag (gesprochen mit ä). So wird es auch im Artikel Tag_(Informatik) gehalten, und ich habe es auch noch nie anders gehört; ich könnte also versucht sein, das zu ändern… --Tobias 20:49, 24. Nov. 2007 (CET)
thread_title:  Der Tag oder das Tag? 

message: Die Aussage
:Dies hat den Vorteil, dass die Logik unabhängig vom Design implementiert werden kann.
ist entweder banal (natürlich kann man ein Design ohne Java entwickeln) oder falsch. In der traurigen Realität bleibt diese Unabhängigkeit nicht lang erhalten.
Zunächst ist jede HTML-Seite eine gültige JSP-Seite. Gut, es kommen Direktiven dazu – geschenkt; die sollten bei Ansicht mit einem Browser noch ignoriert werden. Es geht los, wenn variable Inhalte eingefügt werden (also eigentlich immer).
;Die traurige Realität
Erstes Beispiel: Ersetzung einer Variablen
Einmal abgesehen von dem Java-Code, der üblicherweise nötig ist, um die Variable zu deklarieren – außerhalb des HTML-Codes, sodaß das Template als HTML-Dokument schon nicht mehr valide ist – sieht das in JSP etwa so aus (es handele sich z. B. um eine Anzahl in einer Tabellenzelle):
 <%= anzahl %>
Das kann man so schon keinem Designer mehr in die Hand drücken, der am Layout der Seite noch etwas ändern soll; anstelle einer Zahl steht dort entweder <%= anzahl %>, nichts (weil es wie ein Tag anfängt, der Browser dieses aber nicht kennt), oder die Tabellenzelle wird (abhängig vom Browser und den CSS-Styles) gar nicht erst dargestellt; jedenfall sieht es nicht aus wie eine Zahl. Aber das ist noch harmlos.
Zweites Beispiel: Füllen einer Tabelle
Die Zeilen einer Tabelle werden üblicherweise über einen ListElementRenderer gefüllt: es wird über Elemente einer Liste iteriert, und jedes einzelne Element wird über einen Aufruf des ListElementRenderers erzeugt, komplett mit allen HTML-Tags. Die aber sind das Design (sollte das nicht getrennt sein?), und sie werden von handprogrammiertem Java-Code (Logik) erzeugt. Die JSP-Seite enthält an dieser Stelle kein HTML mehr, und bei Betrachtung mit einem Browser bekommt man dementsprechend keinerlei Eindruck vom Ergebnis.
Im Ergebnis wird oft genug das Layout in Form von Screenshots geliefert, die mit Styleguide und CSS-Klassen des Unternehmens konform gehen/realisierbar sind oder auch nicht, und Programmierer dürfen sich den Kopf über Designfragen zerbrechen; der generierte HTML-Code ist oft genug von zweifelhafter Qualität. Wenn man also mal ein echtes Problem damit hat, hilft der HTML-Validator kaum weiter, weil der Code ohnehin voller Fehler ist. Es wird Arbeitszeit verbrannt ohne Ende, nur aufgrund eines veralteten Konzepts, das vielleicht noch taugte, als mit PHP noch das „Personal Homepage Tool“ war und damit kleine Sites für den Privatgebrauch gestrickt wurden; denn die Abwechslung von Java-Code mit HTML ist die gleiche schlechte Idee.
;Die bessere Idee
Die bessere Idee besteht darin, die dynamischen Inhalte über HTML- (bzw. X[H]ML-) Attribute einzufügen, wie das z.B. die Template Attribute Language vorsieht (und möglicherweise auch neuere Java-Frameworks, Beispiele würden mich interessieren):
 
   3
   Goldhamster
   19,99
   59,97
 
Ein [X]HTML-Browser wird beim Betrachten die speziellen Attribute ignorieren und folgendes als Prototyp für reale Daten interpretieren (eine simple HTML-Tabellenzeile):
 
   3
   Goldhamster
   19,99
   59,97
 
Die Syntax ist selbsterklärend (und wer sie kompliziert findet, bedenke, daß sie den kompletten ListElementRenderer ersetzt, der sehr viel länger ist): item ist die Schleifenvariable, die nacheinander den Wert aller Elemente der Sequenz annimmt; es handelt sich um ein Objekt mit den Eigenschaften anzahl, name, preis und gesamt (bzw. den entsprechenden Getter-Methoden getAnzahl usw.). Der Java-Code ist damit nur noch für die Lieferung der Daten zuständig, während das Layout vollständig im Template definiert wird. Mit einem möglichen Attribut fmt:formatter="waehrung" würde im Beispiel angegeben, daß der Wert als Geldbetrag formatiert ausgegeben werden soll, also mit zwei Nachkommastellen (abhängig von der Währung) und mit Dezimalkomma (abhängig von der Sprache). Die Templating-Engine stellt sicher, daß ordentlicher Code erzeugt, also jedes geöffnete Tag auch wieder geschlossen wird.
Der große Vorteil ist also, daß Designer und Programmierer sehr viel besser zusammenarbeiten können; der um die speziellen Attribute ergänzte Prototyp kann wie eine JSP-Seite automatisch in eine Java-Klasse übersetzt werden, und er kann problemlos vom Designer weiterbearbeitet werden, wenn Änderungen am Layout ausgeführt werden müssen. Er/sie/das verwendete Werkzeug muß lediglich die speziellen Attribute unberührt lassen. Layouts können entwickelt und getestet werden, ohne daß die Logik schon funktionieren muß.
JSP hat „Vorteile“ nur, wenn man es mit der Generierung von Code ohne jede Templatesprache vergleicht; es ist überholt und gehört auf den Müllhaufen der Geschichte. Leider werden damit immer noch sehr viel Zeit, Geld und Nerven verschwendet. --Tobias 00:03, 25. Nov. 2007 (CET)
replies: text: Tut mir leid aber Du weisst nicht, wovon Du sprichst. PHP wie JSP sind dynamische Sprachen, und als Designer muss ich das Tag auch nicht übersetzt angezeigt bekommen, es genügt der Source-Code. Versuchs mal mit 'nem Dreamweaver oder so...zudem gibt's WYSIWYGS inkl. Serverunterstützung damit Du eine Zahl siehst. (PS: den obigen Kommentar könnte ein Admin löschen) --178.197.237.8 16:37, 22. Mai 2013 (CEST)
replies: text: Liebe IP - Admins löschen keine Kommentare, nur weil irgendwelche IPs sie als falsch empfinden. Und mit deinen Anschuldigungen hier ("Du weisst nicht, wovon Du sprichst") und an anderer Stelle wäre ich gerade an deiner Stelle etwas vorsichtiger. --Sebastian.Dietrich  ✉ 17:24, 22. Mai 2013 (CEST)
thread_title:  Ein Konzept von gestern 

message: Mittlerweile gibt es die Diskussion ja häufiger, aber JSP ist eine Technik, keine Technologie (siehe Definition der Worte). Das ist leider eine weit verbreitete (und bis vor kurzem auch von mir benutzte) Unart. --Jens.
(Der vorstehende Beitrag stammt von 84.180.1.70 – 17:11, 9. Aug. 2008 (MESZ)
thread_title:  Technik, nicht Technologie 

message: – GiftBot (Diskussion) 03:57, 27. Nov. 2015 (CET)
thread_title:  {{Anker|deadurl_2015-10}} Defekte Weblinks 

message: Jakarta Server Pages (JSP). Dazu hier. --Duisburg 2021 (Diskussion) 09:10, 12. Feb. 2021 (CET)
thread_title:  Verschiebung des Artikels