Hallo,
es geht mir um Anwendungen mit einer allgemeinen üblichen Seiten-Struktur wie:
* Header (Header-Grafik und ein paar Menüpunkte wie Impressum, AGB, Kontakt, usw.)
* Spalte mit Haupt-Menü
* Spalte mit Content
* Footer
So eine Struktur lässt sich ja grundsätzlich schon mal ganz angenehm über Tiles definieren.
Jetzt hab ich jene Vorgehensweise gewählt, die vom Prinzip her in der PHP-Welt ja weit verbreitet ist, allein schon, weil ich sonst gar nicht wüsste, wie ich es sonst angehen sollte, ohne lauter redundanten (bestenfalls unelegant und unflexibel) oder invaliden HTML-Code zu produzieren (und da die komplette Seite, nicht nur z.B. der Kundenbereich, in JSF / PrettyFaces geschrieben und anschließend konsequent suchmaschinenfreundlich sein soll, muss der HTML-Code schon valide sein
):
Bei jedem Seitenaufruf wird eine JSP aufgerufen, die die seitenspezifischen Daten bereitstellt - und im Prinzip reicht da ja schon ein einziger Index, um in der weiteren Folge alle benötigten Daten aus Arrays bzw. HashMaps oder, wenn es sein muss, auch aus der Datenbank, auslesen zu können - und anschließend eine zentrale JSP inkludiert, die die Seitenstruktur unter Befüllung mit den unterseitenspezifischen Daten (Bezug zum o.g. HashMap-Key) aufbaut.
Beispielsweise wird über irgendwelche HashMaps hinterlegt
(alles Pseudo-Code, wie der geschulte Programmierer sofort merken wird):
________________________________________________________________________________________________
Schlüssel "impressum": Seitentitel = "Impressum", Description = "Unser Impressum", Content = "_impressum.jsp", Seitenueberschrift = "Impressum"
Schlüssel "kontakt": Seitentitel = "Kontakt", Description = "Nehmen Sie Kontakt auf", Content = "_kontakt.jsp", Seitenueberschrift = "Kontakt aufnehmen..."
usw.
________________________________________________________________________________________________
Die jeweils aufgerufene Seite soll also nur den Schlüssel für die hinterlegten HashMaps setzen, sodass die unmittelbar darauf inkludierte zentrale JSP (nennen wir sie mal main.jsp) die richtigen Daten für <title>...</title>, <meta name="description" content="..."></meta>, den Content-Bereich, usw. bereitgestellt bekommt.
Bsp.:
impressum.jsp:
______________________________
setze Schlüssel = "impressum"
inkludiere main.jsp
______________________________
main.jsp (im Endeffekt wiederum zerlegt in ein paar Tiles-Seiten):
__________________________________________________
...
<html>
<head>
<title>hole den zum Schlüssel passenden Titel</title>
<meta name="description" content="hole die zum Schlüssel passende Description"></meta>
...
Einbindung des zum Schlüssel passenden Contents
...
__________________________________________________
Jetzt gibt es noch ein eigentlich kleines, aber doch gewichtiges Problem beim Setzen des HashMap-Schlüssels:
Wie lässt sich in JSF ein Wert (typischerweise Property) setzen?
Ich suche also so etwas wie <jsp:setProperty ... >, was sich reibungslos in JSF einfügt.
Wenn ich z.B. aus JSF heraus den Bean-Konstruktur mit Parameter aufrufen könnte, wäre das Problem gelöst.
.
es geht mir um Anwendungen mit einer allgemeinen üblichen Seiten-Struktur wie:
* Header (Header-Grafik und ein paar Menüpunkte wie Impressum, AGB, Kontakt, usw.)
* Spalte mit Haupt-Menü
* Spalte mit Content
* Footer
So eine Struktur lässt sich ja grundsätzlich schon mal ganz angenehm über Tiles definieren.
Jetzt hab ich jene Vorgehensweise gewählt, die vom Prinzip her in der PHP-Welt ja weit verbreitet ist, allein schon, weil ich sonst gar nicht wüsste, wie ich es sonst angehen sollte, ohne lauter redundanten (bestenfalls unelegant und unflexibel) oder invaliden HTML-Code zu produzieren (und da die komplette Seite, nicht nur z.B. der Kundenbereich, in JSF / PrettyFaces geschrieben und anschließend konsequent suchmaschinenfreundlich sein soll, muss der HTML-Code schon valide sein
Bei jedem Seitenaufruf wird eine JSP aufgerufen, die die seitenspezifischen Daten bereitstellt - und im Prinzip reicht da ja schon ein einziger Index, um in der weiteren Folge alle benötigten Daten aus Arrays bzw. HashMaps oder, wenn es sein muss, auch aus der Datenbank, auslesen zu können - und anschließend eine zentrale JSP inkludiert, die die Seitenstruktur unter Befüllung mit den unterseitenspezifischen Daten (Bezug zum o.g. HashMap-Key) aufbaut.
Beispielsweise wird über irgendwelche HashMaps hinterlegt
(alles Pseudo-Code, wie der geschulte Programmierer sofort merken wird):
________________________________________________________________________________________________
Schlüssel "impressum": Seitentitel = "Impressum", Description = "Unser Impressum", Content = "_impressum.jsp", Seitenueberschrift = "Impressum"
Schlüssel "kontakt": Seitentitel = "Kontakt", Description = "Nehmen Sie Kontakt auf", Content = "_kontakt.jsp", Seitenueberschrift = "Kontakt aufnehmen..."
usw.
________________________________________________________________________________________________
Die jeweils aufgerufene Seite soll also nur den Schlüssel für die hinterlegten HashMaps setzen, sodass die unmittelbar darauf inkludierte zentrale JSP (nennen wir sie mal main.jsp) die richtigen Daten für <title>...</title>, <meta name="description" content="..."></meta>, den Content-Bereich, usw. bereitgestellt bekommt.
Bsp.:
impressum.jsp:
______________________________
setze Schlüssel = "impressum"
inkludiere main.jsp
______________________________
main.jsp (im Endeffekt wiederum zerlegt in ein paar Tiles-Seiten):
__________________________________________________
...
<html>
<head>
<title>hole den zum Schlüssel passenden Titel</title>
<meta name="description" content="hole die zum Schlüssel passende Description"></meta>
...
Einbindung des zum Schlüssel passenden Contents
...
__________________________________________________
Jetzt gibt es noch ein eigentlich kleines, aber doch gewichtiges Problem beim Setzen des HashMap-Schlüssels:
Wie lässt sich in JSF ein Wert (typischerweise Property) setzen?
Ich suche also so etwas wie <jsp:setProperty ... >, was sich reibungslos in JSF einfügt.
Wenn ich z.B. aus JSF heraus den Bean-Konstruktur mit Parameter aufrufen könnte, wäre das Problem gelöst.
.
Zuletzt bearbeitet: