Search the FirstSpirit Knowledge Base
Hallo zusammen,
ich suche mit FS Integration in einer Tabelle nach bestimmten Datensätzen. Ein Attribut des Datensatzes ist ein Link auf ein Bild. Wenn ich das ausgebe <c:out value="${m.vorschaubild}" /> bekomme ich xml angezeigt.
<CMS_VALUE name="cs_vorschaubild" tag="CMS_INPUT_PICTURE"><LANG id="§" set="1"><REF>media:_4212601_kl</REF><ALT></ALT><REMOTE/><WIDTH>71</WIDTH><HEIGHT>70</HEIGHT><HSPACE/><VSPACE/><BORDER/></LANG></CMS_VALUE>
Wie komme ich an die richtige Url?
Grüße,
Claus Kolb
Hallo,
was ergibt die Ausgabe des Vorschaubildes, wenn Sie auf den Wert ohne <c:out value> zugreifen, also nur ${m.vorschaubild} . Wir benutzen sowas ähnliches innerhalb von <fsi:iterateResults> und da benutzen wir kein <c:out>
Viele Grüße
Die Url eines Mediums hängt von verschiedenen Faktoren ab:
Die korrekte Url kann eigentlich nur zur Generierungszeit ermittelt werden. Die praktikabelste Lösung ist eine Contentprojektion (mit einer Tabellenvorlage) zu verwenden, die für jeden Datensatz das Vorschaubild (img Tag) generiert. Dieses HTML-Schnipsel können sie dann per JSP/JSTL in ihre eigentliche Seite inkludieren.
Das gleiche Problem haben Sie übrigens auch bei anderen Komplexen Eingabekomponenten (DOM etc.). Einige Kunden arbeiten auch mit einer einfachen Mapping-Datei (Datensatz-ID -> Url des Schnipsels).
Nun ja.
Theoretisch gibt es auch bei einfachem Text eine Sprach-Umschaltung, etc.
Außerdem erzeugt FS ja schließlich auch ansonsten die korrekten Link-Adressen, trotz der genannten Punkte.
Ein extrem hässliche Lösung wäre in diesem Fall ja, sich die URL selbstständig zusammenzubauen, da es ja für alle anderen Bilder auf der Seite auch klappt.
Mittels <c:out value="..."/> bekommt man zumindest das komplette xml als String zurück. Darin steht dann z.B. media:datei01 drin.
Man nimmt also den Link eines anderen Bildes (das im gleichen Ordner stehen muss) und ersetzt den Dateinamen mit dem in dem XML angegeben Wert. Die Dateiendung muss man raten oder separat hinterlegen.
Es geht also, ich verstehe nur nicht, warum das im Integration Modul nicht ordentlich umgesetzt wurde. Da lohnt es sich eher, ganz auf FS zu verzichten und die Bilder // PDFs etc. extern zu pflegen, wenn es nicht möglich ist, dass man auf die URL zugreifen kann.
Martin Herschke schrieb:
Nun ja.
Theoretisch gibt es auch bei einfachem Text eine Sprach-Umschaltung, etc.
In den Datenquellen gibt es für jede Sprache eine entsprechende Spalte, insofern stellt dies kein Problem dar. Die Webseite kennt ja ihre Sprache und kann die entsprechende Spalte auslesen.
Martin Herschke schrieb:
Außerdem erzeugt FS ja schließlich auch ansonsten die korrekten Link-Adressen, trotz der genannten Punkte.
Ja, aber wie ich bereits schrieb, sind diese Punkte erst zum Generierungszeitpunkt bekannt. Der direkte Zugriff auf die Datenbank (mittels Integration) umgeht die Generierung.
Martin Herschke schrieb:
Ein extrem hässliche Lösung wäre in diesem Fall ja, sich die URL selbstständig zusammenzubauen, da es ja für alle anderen Bilder auf der Seite auch klappt.Mittels <c:out value="..."/> bekommt man zumindest das komplette xml als String zurück. Darin steht dann z.B. media:datei01 drin.
Man nimmt also den Link eines anderen Bildes (das im gleichen Ordner stehen muss) und ersetzt den Dateinamen mit dem in dem XML angegeben Wert. Die Dateiendung muss man raten oder separat hinterlegen.
Das hat die bereits genannten Nachteile, die nachzubauenende Logik ist einfach zu komplex, zumindest wenn sie eine generische Lösung haben wollen. Selbst wenn Sie die Url richtig zusammengebaut haben, ist das Medium dann noch lange nicht unter dieser Url verfügbar. Das Medium muss vorher auch generiert und deployed worden sein.
Was spricht denn gegen den Ansatz den Image-Tag als Html-Schnipsel zu generieren und diesen mittels JSP-Include in die Seite einzufügen? Die Variante ist in wenigen Minuten erstellt (neue Tabellenvorlage anlegen, HTML-Kanal befüllen, Seite anlegen, Datenreiter konfigurieren). Die generierten Seiten haben die FS_ID des Datensatzes als Postfix (z.B. productimage_1242.html). Die Seite wird in das gleiche Verzeichnis wie ihre eigentliche Seite gelegt, so dass der JSP-Include entsprechend simpel umzusetzen ist.
Eventuell macht es auch Sinn nicht nur den Image-Tag als Schnipsel zu rendern, sondern einen größeren HTML-Block, der eventuell auch formatierten Text (DOM) enthält.
Sie ersparen sich einfach viel Arbeit, wenn sie die Stärken eines vorgenerierenden Systems nutzen, anstatt möglichst viel "live" machen zu wollen. Mit einem schlauen und kurzen Deployment bringt "live" auch keinen Geschwindigkeitsvorteil mehr.
Christoph Feddersen schrieb:
Ja, aber wie ich bereits schrieb, sind diese Punkte erst zum Generierungszeitpunkt bekannt. Der direkte Zugriff auf die Datenbank (mittels Integration) umgeht die Generierung.
Es geht darum, dass das INTEGRATION Suchfeld, womit man die Suche startet, auf einer deployten Seite zur Verfügung gestellt wird. Dadurch ist der Kontext des Suchfeldes klar... sprich:
Wenn ich eine Suchseite unter "www.example.de/de/search.html" verwende und ich dann eine Suche nach einem Bild aussuche, dann steht fest, dass die Basis-URL "www.example.de" heißt.
Da die Medienverwaltung in FirstSpirit der Ordnerstruktur im deploytem Zustand entspricht, weiß man auch, dass ein Bild, dass in "Medienverwaltung -> img -> icons" liegt, später auch in dem entsprechenden Unterordner landet.
Christoph Feddersen schrieb:
Selbst wenn Sie die Url richtig zusammengebaut haben, ist das Medium dann noch lange nicht unter dieser Url verfügbar. Das Medium muss vorher auch generiert und deployed worden sein.
Das stimmt schon, doch das sind generelle Probleme, die man ansonsten auch in FirstSpirit hat (nicht deployte Seiten werden wohl kaum angezeigt). Gleiches gilt bei externen Datenbanken. Ist der Server nicht verfügbar, etc., kann das Bild nicht angezeigt werden.
Christoph Feddersen schrieb:
Was spricht denn gegen den Ansatz den Image-Tag als Html-Schnipsel zu generieren und diesen mittels JSP-Include in die Seite einzufügen? Die Variante ist in wenigen Minuten erstellt (neue Tabellenvorlage anlegen, HTML-Kanal befüllen, Seite anlegen, Datenreiter konfigurieren).
Die grundlegende Philosophie ist in meinen Augen bereits verkehrt.
Im Klartext bedeutet dieser Ansatz:
Zusammenfassend könnte man sagen, dass man die Datenbank auch hätte rausschmeißen können => sie wird ja in diesen Ansatz während des Generierungsvorganges nach ALLEN Einträgen durchsucht, die dann in eine Datei geschrieben werden... vermutlich in eine HTML Datei.
Dies widerspricht meiner Meinung nach doch stark dem Ansatz einer Datenbank. Verglichen mit externen Alternativen, die einfach eine URL speichern, hat man wesentlich weniger Redundanz (ein DB Eintrag eines komplexen Datenfeldes liegt dann nicht als Datei UND als jsp Schnipsel vor).
Für einen konkreten Anwendungsfall kann man die Url zu einem Medium im Livesystem ermitteln. Dort können definieren, dass Urls immer nur über den Default-UrlCreator erzeugt werden, es keine sprachabhängigen Medien geben darf und keine Remote-Medien eingesetzt werden. Sie müssen also nur noch sicherstellen, dass die Medien auch irgendwie deployed werden.
Einen generische Lösung ist aber deutlich aufwendiger, aus den bereits genannten Gründen. Deswegen gibt es solch eine Funktionalität momentan auch nicht.
Martin Herschke schrieb:
Im Klartext bedeutet dieser Ansatz:
- Man schreibt die KOMPLETTE Datenbank in eine Datei (oder wenn man möchte für 500 Bilder auch in 500 Dateien).
- Man ruft ein Servlet auf, dass die Datenbank durchsucht und eine ID erzeugt
- Aus der ID + einer Grund-URL Adresse baut man sich die komplette Adresse zusammen
- Mittels JSP wird dann nach einer Quelle mit der zusammengesetzten URL gesucht, die dann eingebunden wird.
Man schreibt nicht die kompletten Daten der Tabelle/Datenbank in Dateien, sondern nur die Html-Schnipsel, die man für die Darstellung braucht. Das kann ein großes Schnipsel sein, also ein komplettes Suchergebnis inklusive Bild, Überschrift, Link und Beschreibungstext. Alternativ schreibt man mehrere kleine Schnipsel heraus (nur das Bild, nur den formatierten Text). Dies geschieht über eine Contentprojektion, bei denen die FS-ID immer im Dateinamen vorkommt. Man braucht also nicht mehrmals suchen, sondern benutzt FS-Integration um ganz normal in der Datenbank zu suchen. Bei der Ausgabe sind dann keine weiteren Suchen mehr notwendig, da man die Url des korrekten Schnipsel einfach zusammenbauen kann (/de/schnipsel/suchergebnis_FS-ID.html).
Martin Herschke schrieb:
Zusammenfassend könnte man sagen, dass man die Datenbank auch hätte rausschmeißen können => sie wird ja in diesen Ansatz während des Generierungsvorganges nach ALLEN Einträgen durchsucht, die dann in eine Datei geschrieben werden... vermutlich in eine HTML Datei.
Wie gesagt, FirstSpirit ist ein vorgenerierendes System. Insofern liegen alle Daten redundant vor, nämlich im Redaktionssystem (FirstSpirit) und in der Liveseite(n). Ggf. gibt es auch mehrere Ausgabekanäle wie Html und PDF. Wichtig ist doch nur, dass die Daten nur einmal im Redaktionssystem vorliegen und somit an einer Stelle geändert werden können.
Dynamische Systeme, die oft eine Datenbank zur Speicherung nutzen, arbeiten hier anders. Dort wird dann bei jedem Zugriff auf die Liveseite die Information aus der Datenbank geholt. Um Performance und Skalierbarkeit zu gewährleisten, werden verschiedene Caching-Layer verwenden, so dass die Daten auch dort redundant vorliegen.
Es wäre super wenn Sie bitte eine ausführlichere Beschreibung mit den einzelnen Schritten und Beispielen schreiben könnten.
Ich denke für die "newb-s" wäre die obengenannte Erklärung leider nicht sehr verständlich.
Ich habe mich auch mit der Frage beschäftigt wie man mittels FSI eine Datei hochladen kann. Bisher habe ich zu diesem Thema noch keine Antwort gefunden. Wurde das von FSI unterstützt? Falls nicht, könnten Sie bitte eventuell eine Lösung ala "best practice" für dieses Problems nennen?
Ich bedanke mich im Voraus.
Mfg
Gibt es hierzu mittlerweile ein Beispiel? Ich stehe ebenfalls vor dem Problem, dass ich diverse DOM-Felder ausgeben muss. Leider stehe ich bei der Beschreibung auf dem Schlauch.