Diskussion:Jakarta Server Pages

aus Wikipedia, der freien Enzyklopädie
Letzter Kommentar: vor 3 Jahren von Duisburg 2021 in Abschnitt Verschiebung des Artikels
Zur Navigation springen Zur Suche springen
Diese Diskussionsseite dient dazu, Verbesserungen am Artikel „Jakarta Server Pages“ zu besprechen. Persönliche Betrachtungen zum Thema gehören nicht hierher. Für allgemeine Wissensfragen gibt es die Auskunft.

Füge neue Diskussionsthemen unten an:

Klicke auf Abschnitt hinzufügen, um ein neues Diskussionsthema zu beginnen.

JavaServer Pages für Dummies

[Quelltext bearbeiten]

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) – und wurde nachträglich signiert.)

wäre möglicherweise im Artikel auch praktisch - vielleicht ein Kapitel Namensgebung oder so.--Slartidan 14:53, 24. Feb 2006 (CET)

Ein Hinweis zur Namensgebung JSP stand (bevor es JavaServer-Pages gab) für Jackson Structured Programming, wie in der Wikipedia unter dem Eintrag zu Michael A. Jackson auch erwähnt.
(Der vorstehende Beitrag stammt von 212.14.78.131 – 13:08, 30. Jun. 2006 (MESZ) – und wurde nachträglich signiert.)

Der Abschnitt Aktionen

[Quelltext bearbeiten]

Die Erklärung von jsp:param unter "Aktionen" ist mir unklar.
Falls der Parameter schon im Request vorhanden war, wird der Neue an den Anfang der Liste gesetzt. Beispiel: foo=bar, foo/neu wird hinzugefügt. Ergebnis: foo=neu,bar
Vorher gibt es nur den Parameter foo, dessen Wert bar ist. Dann wird was hinzugefügt? foo oder neu oder beide? Mit jeweils welchem Wert? Und das Ergebnis: Wieso ist neu, das als neuer Parameter hinzugefügt wurde, plötzlich der Wert von foo? Und bar ist plötzlich leer? Bitte um Klärung.
Gleiches gilt für jsp:useBean. Welche Attribute stehen wem zur Verfügung? Die Attribute der Seite stehen der Bean zur Verfügung oder umgekehrt? Und was genau bedeutet "stehen zur Verfügung"?
--MauriceKA 09:30, 15. Dez 2005 (CET)

jsp:param war einfach nur falsch - die Ausführungen zu jsp:useBean etwas ungenau. Ich habe beides angepasst. Hier könnte man noch einiges mehr hinzufügen aber ganz high-level ist das schon ok so.
--Michael Hüttermann 00:05, 27. Feb 2006 (CET)

Expression Language

[Quelltext bearbeiten]

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) – und wurde nachträglich signiert.)

Der Tag oder das Tag?

[Quelltext bearbeiten]
Letzter Kommentar: vor 16 Jahren1 Kommentar1 Person ist an der Diskussion beteiligt

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)Beantworten

Ein Konzept von gestern

[Quelltext bearbeiten]
Letzter Kommentar: vor 11 Jahren3 Kommentare3 Personen sind an der Diskussion beteiligt

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): 

<td><%= anzahl %></td>

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):

<tr tal:repeat="item items"
    tal:define="waehrung meine.klasse.zur.formatierung.von.geldbetraegen">
   <td tal:content="item/anzahl">3</td>
   <td tal:content="item/name">Goldhamster</td>
   <td tal:content="item/preis"
       fmt:formatter="waehrung">19,99</td>
   <td tal:content="item/gesamt"
       fmt:formatter="waehrung">59,97</td>
 </tr>

Ein [X]HTML-Browser wird beim Betrachten die speziellen Attribute ignorieren und folgendes als Prototyp für reale Daten interpretieren (eine simple HTML-Tabellenzeile):

<tr>
   <td>3</td>
   <td>Goldhamster</td>
   <td>19,99</td>
   <td>59,97</td>
 </tr>

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)Beantworten

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)Beantworten
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)Beantworten

Technik, nicht Technologie

[Quelltext bearbeiten]

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) – und wurde nachträglich signiert.)


[Quelltext bearbeiten]
Letzter Kommentar: vor 8 Jahren1 Kommentar1 Person ist an der Diskussion beteiligt
Die folgenden Weblinks wurden von einem Bot („GiftBot“) als nicht erreichbar erkannt.
  • Ausführliche Erläuterungen und Hilfe zur korrekten Behebung dieser Fehler finden sich auf Wikipedia:Defekte Weblinks.
  • Ist ein von einem Bot als defekt gemeldeter externer Link doch erreichbar, dann bitte berichten – wie auch sonstige Probleme.

– GiftBot (Diskussion) 03:57, 27. Nov. 2015 (CET)Beantworten

Es wird nichts dynamisch Erzeugt, sondern dynamisches HTML erzeugt...

[Quelltext bearbeiten]

Der erste Satz sollte umformuliert werden und der Beschreibung auf Oracle (http://www.oracle.com/technetwork/java/javaee/jsp/index.html) gleichen. JavaServer Pages (JSP) technology provides a simplified, fast way to create dynamic web content. Es wird nicht dynamisch Erzeugt, sondern dynamisches HTML erzeugt.

Verschiebung des Artikels

[Quelltext bearbeiten]
Letzter Kommentar: vor 3 Jahren1 Kommentar1 Person ist an der Diskussion beteiligt

Jakarta Server Pages (JSP). Dazu hier. --Duisburg 2021 (Diskussion) 09:10, 12. Feb. 2021 (CET)Beantworten

Abgerufen von „https://de.wikipedia.org/w/index.php?title=Diskussion:Jakarta_Server_Pages&oldid=208717522“