nicht angemeldet
Infos über SSI?
Hallo,
ich bräuchte mal gute Links, Tutorials und ähnliches zu SSI. Kann mir vielleicht auch jemand kurz und bündig erklären, wozu man SSI vorrangig verwendet?
Grüsse
dave
-
ich bräuchte mal gute Links, Tutorials und ähnliches zu SSI. Kann mir vielleicht auch jemand kurz und bündig erklären, wozu man SSI vorrangig verwendet?
http://httpd.apache.org/docs/howto/ssi. Mehr brauchst Du nicht (ok, es sei denn, Du kannst überhaupt kein Englisch:).
SSI benutzt man für ziemlich genau denselben Zweck, für den (leider) auch Frames benutzt werden: Immer wiederkehrende Seitenelemente in eine Seite einbinden, ein Menü zum Beispiel, oder Seitenkopf und -fuß.
Du hast so ein wiederkehrendes Element dann in einer einzelnen Datei stehen und brauchst bei Änderungen nur noch diese eine Datei ändern anstatt Dich durch sämtliche 180 restliche Seiten des Angebots zu wühlen, die dieses Element benutzen.Gruß,
soenk.e-
Hi Sönke,
SSI benutzt man für ziemlich genau denselben Zweck, für den (leider)
auch Frames benutzt werden:au weia. Da ist ja nun praktisch _kein_ wahres Wort dran. Frames sind
beispielsweise in einer ganz anderen Weise auf dem Bildschirm sichtbar
als via SSI eingebundene Inhalte. Wenn Du wenigstens "Iframes" gesagt
hättest ... das wäre so halbwegs hingekommen.Ich versuche es also mal anders:
Server Side Includes sind dazu da, innerhalb eines Dokuments Befehle
(einfacher Art) auszuführen. Einer dieser Befehle ist in der Tat das
Einfügen von anderen HTTP-Inhalten (das sind syntaktisch wiederum
URLs und können folglich auch Programmaufrufe etc. sein).
SSI kann noch ein paar zusätzliche Befehle, etwa das Auflisten von
Inhalten aus Environment-Variablen, das Einblenden des Datums der
letzten Änderung der Datei, in welcher diese Anweisung steht usw.XSSI (extended Server Side Includes - das wird vom Apache-Webserver
unterstützt) kann da schon mehr, beispielsweise nun auch Wertzuwei-
sungen an Variablen, Auswertung von Ausdrücken (mit regular expres-
sions) und bedingte Verzweigungen (einfaches if-then-else).
Keine Schleifen, beispielsweise - mit dem Umfang von PHP oder Perl
kann SSI nicht mithalten, das ist auch nicht der Sinn der Sache.Aber für einfache Abfragen, etwa bedingte Reaktionen auf Browser,
oder auch für die Abfrage eines Query-String-Parameters, ist SSI eine
ressourcensparende Alternative zu den Interpretern mächtigerer server-
seitiger Interpretersprachen. Und es ist im Webserver definitiv drin,
muß also nicht als separates Produkt installiert werden.Viele Grüße
Michael-
SSI benutzt man für ziemlich genau denselben Zweck, für den (leider)
auch Frames benutzt werden:au weia. Da ist ja nun praktisch _kein_ wahres Wort dran. Frames sind
beispielsweise in einer ganz anderen Weise auf dem Bildschirm sichtbar
als via SSI eingebundene Inhalte.Du möchtest mir doch nicht etwa weißmachen, daß SSI nur deshalb erfunden wurde, weil man damit so sensationelle Möglichkeiten wie
das Auflisten von Inhalten aus Environment-Variablen,
das Einblenden des Datums der letzten Änderung der Datei,hat? Der Kern von SSI ist doch wohl wirklich das Einfügen von immer wiederkehrenden Dokumentfragmenten, um sich das Erstellen von Webseiten zu erleichtern. Warum heißt es denn wohl Server Side _Includes_ und nicht Server Side Variables?
Solche Fragmente sind, wie ich geschrieben habe, zum Beispiel Menü, Kopf und Fuß einer Seite. Und was wird in der Regel mit Frames gemacht? Dasselbe, Menü, häufig auch ein Seitenkopf, manchmal auch ein Seitenfuss.
Mir persönlich ist wirklich keine Seite bekannt, die Frames für etwas anderes einsetzt. Und IMHO ist das Einbinden von Fragmenten nach wie vor der Hauptanwendungszweck von SSI.Deine Erklärung mag umfangreicher und pauschaler sein, aber das ich Unwahrheiten verbreitet haben soll, sehe ich nicht ein.
Gruß,
soenk.e-
Hi Sönke,
Der Kern von SSI ist doch wohl wirklich das Einfügen von immer
wiederkehrenden Dokumentfragmenten,richtig. Nur: Was soll das mit Frames zu tun haben?
Solche Fragmente sind, wie ich geschrieben habe, zum Beispiel Menü,
Kopf und Fuß einer Seite. Und was wird in der Regel mit Frames
gemacht? Dasselbe, Menü, häufig auch ein Seitenkopf, manchmal auch
ein Seitenfuss.Weder Seitenkopf noch Seitenfuß machen Sinn via Frames, weil eine
Seite variabel lang ist, ein Frame-Fenster aber nur konstant hoch.Menüs wiederum machen eben gerade mit Frames mehr Sinn als mit SSI,
weil sie mit reinem via SSI eingefügtem HTML beim Scrollen innerhalb
des Dokuments aus dem Blickfeld verschwinden, während sie als sepa-
rater Frame sichtbar bleiben. Erst mit CSS und Positionierung _und_
einem Browser, der das auch unterstützt (also nicht M$IE!) lassen
sich Frames so halbwegs simulieren - und in der Tat verwende ich
_dann_ auch selbst SSI zu diesem Zweck (gzip_cnc, beispielsweise).Mir persönlich ist wirklich keine Seite bekannt, die Frames für
etwas anderes einsetzt.Dann schau Dir mal www.schroepl.net an (mit aktivem JavaScript) und
versuche, das alles mit SSI zu lösen - vor allem die Gedächtnis-
funktionen der geschachtelten Frames. Viel Spaß dabei.Deine Erklärung mag umfangreicher und pauschaler sein, aber das ich
Unwahrheiten verbreitet haben soll, sehe ich nicht ein.Es mag in Teilbereichen gewisse thematische Überschneidungen zwischen
Frames (der Aufteilung des Browserfensters in mehrere unabhängige
Dokumente) und der Möglichkeit zur dynamischen Zusammenfügung eines
Dokuments aus mehreren Quellen geben, geben, aber Deine pauschale
Gleichsetzung halte ich für falsch und für irreführend.Frames sind eben Frames und kein Dokument - mit allen Vor- und Nach-
teilen, die sie nun mal haben.Viele Grüße
Michael-
Der Kern von SSI ist doch wohl wirklich das Einfügen von immer
wiederkehrenden Dokumentfragmenten,richtig. Nur: Was soll das mit Frames zu tun haben?
Das habe ich bereits zweimal geschrieben:
Solche Fragmente sind, wie ich geschrieben habe, zum Beispiel Menü,
Kopf und Fuß einer Seite. Und was wird in der Regel mit Frames
gemacht? Dasselbe, Menü, häufig auch ein Seitenkopf, manchmal auch
ein Seitenfuss.Weder Seitenkopf noch Seitenfuß machen Sinn via Frames, weil eine
Seite variabel lang ist, ein Frame-Fenster aber nur konstant hoch.Eine "Seite" definiere ich erstmal als das, was man auf dem Bildschirm sieht. Wenn oben ein (im Aussehen) konstanter Bereich mit einer Überschrift ist, dann ist das für mich der Seitenkopf dieses Angebots, ein entsprechender unterer Teil wäre der Seitenfuß, ein Teil mit vielen Verweisen eines Inhaltverzeichnisses das Menü.
Menüs wiederum machen eben gerade mit Frames mehr Sinn als mit SSI,
weil sie mit reinem via SSI eingefügtem HTML beim Scrollen innerhalb
des Dokuments aus dem Blickfeld verschwinden, während sie als sepa-
rater Frame sichtbar bleiben.Ein Seitenkopf/-fuß/-menü definiere ich nicht darüber, ob er sich in irgendeiner Form bewegt, sondern über seinen Inhalt und seinen Bezug zur Seite bzw. zum Angebot.
Weiterhin ging es mir nie um den Sinn und Unsinn der Frage, ob man ein Menü lieber per Frame oder per SSI einbindet/anzeigt. Es geht darum, was der Leser auf seinem Bildschirm zu sehen kriegt.
Mir persönlich ist wirklich keine Seite bekannt, die Frames für
etwas anderes einsetzt.Dann schau Dir mal www.schroepl.net an (mit aktivem JavaScript) und
Und was sehe ich da? Einen Seitenkopf "Spiele per Post - Michael Schröpl", links ein Menü, unten ein Menü, zusammengesetzt zu einer kompletten Seite (oder meinetwegen: komplettes Angebot) per Frameset.
Der einzige Unterschied, den hier ein Einbinden per SSI gemacht hätte, wäre, daß die einzelnen Teile sich mit dem Seiteninhalt bewegt hätten. - das ändert aber doch wohl nichts an ihrer Funktion.
versuche, das alles mit SSI zu lösen - vor allem die Gedächtnis-
funktionen der geschachtelten Frames. Viel Spaß dabei.Ich habe nirgendwo behauptet, daß Frames exakt dieselben Möglichkeiten bieten wie SSI. Ich habe lediglich gesagt, daß man sowohl SSI als auch Frames in der Regel dazu benutzt, um "Immer wiederkehrende Seitenelemente in eine Seite ein[zu]binden, ein Menü zum Beispiel, oder Seitenkopf und -fuß." Ersetze "Seite" durch "Angebot", wenn's sein muß.
Natürlich ist die Technik unterschiedlich. Aber darum geht es garnicht, es geht um den Nutzen und das Ergebnis, nicht die Maschinerie dahinter.
Es mag in Teilbereichen gewisse thematische Überschneidungen zwischen
Frames (der Aufteilung des Browserfensters in mehrere unabhängige
Dokumente)Unabhängige Dokumente hast Du vielleicht bei der freenet.de-Suche, bei der im oberen Bereich die Freenet-Leiste erscheint, im unteren Bereich eine fremde Seite aus dem Suchergebnis.
Selbst das könnte noch unter meine Definition von "Zusammenführung von Seitenkopf oder einem Menü mit dem eigentlichem Inhalt" fallen.Gerade aber bei Deinen Seiten möchte ich das "unabhängige Dokumente" doch als ziemlich weit hergeholt bezeichnen. Deine Menüleisten gehören genauso zum eigentlichen Inhalt wie der Kopf. Wenn die Dinger einzeln stehen (Ausnahme: der eigentliche Inhalt), machen sie keinen Sinn mehr - sie sind also abhängig voneinander.
Nun macht die ganze Diskussion aber keinen Sinn, da Du Frames irgendwie als nicht bewegliche Bereiche definierst, die überhaupt nichts miteinander zu tun haben sollen, ich dagegen immer als Teil einer angezeigten Seite, eines Gesamtbildes.
Insofern können wir uns noch bis Weihnachten streiten, ob Frames hauptsächlich dazu genutzt werden, zum Beispiel ein Menü zusammen mit einer Seite anzuzeigen und ob SSI hauptsächlich dazu genutzt wird, zum Beispiel ein Menü in einer Seite anzuzeigen und insbesondere, wo da der große Unterschied für den Leser sein soll :>Gruß,
soenk.e-
Nun macht die ganze Diskussion aber keinen Sinn, da Du Frames irgendwie als nicht bewegliche Bereiche definierst, die überhaupt nichts miteinander zu tun haben sollen, ich dagegen immer als Teil einer angezeigten Seite, eines Gesamtbildes.
Michael sieht eine Website eben mehr aus Entwicklersicht - aus der (technisch gesehen) bei Frames jede Seite unabhängig von den anderen ist.
Ich tendiere jedoch auch dazu, dass Frames nicht wirklich unabhängig voneinander sind... technisch ja, aber inhaltlich und wenn man es mit der ganzen Website vergleicht, nicht. Einen Endanwender interessiert es nicht, ob das 3 Seiten für sich sind, die nur 'zusammengefügt' sind oder ob das SSI-Elemente oder Layers sind.
Insofern können wir uns noch bis Weihnachten streiten, ob Frames hauptsächlich dazu genutzt werden, zum Beispiel ein Menü zusammen mit einer Seite anzuzeigen und ob SSI hauptsächlich dazu genutzt wird, zum Beispiel ein Menü in einer Seite anzuzeigen und insbesondere, wo da der große Unterschied für den Leser sein soll :>
Hmm... wenn ich mich jetzt an die Stelle hineinversetzen würde, dass ich keine Ahnung von SSI habe, würd ich mich jetzt fragen: Wozu packen Sie Variablen-Funktionen in SSI, wenn das alles und noch mehr schon in PHP enthalten ist?
Grüsse
Lactrik-
Hi Lactrik,
Ich tendiere jedoch auch dazu, dass Frames nicht wirklich unabhängig
voneinander sind... technisch ja, aber inhaltlich und wenn man es mit
der ganzen Website vergleicht, nicht. Einen Endanwender interessiert
es nicht, ob das 3 Seiten für sich sind, die nur 'zusammengefügt' sind
oder ob das SSI-Elemente oder Layers sind.wenn man nicht nur stur _einen_ Navigationsframe hat, sondern mehrere,
dann wird die Unabhängigkeit schon etwas deutlicher.In meinem Falle sind es ineinander geschachtelte Framesets mit jeweils
lokalen Navigations-Frames, also eine "aufgefaltete" Struktur, wie man
sie oft in JavaScript realisiert sieht - nur eben ohne JavaScript.
(Das allerdings zusätzlich eine Gedächtnis-Funktion visualisiert.)Hmm... wenn ich mich jetzt an die Stelle hineinversetzen würde, dass
ich keine Ahnung von SSI habe, würd ich mich jetzt fragen: Wozu packen
Sie Variablen-Funktionen in SSI, wenn das alles und noch mehr schon in
PHP enthalten ist?Die beiden Schwachpunkte dieser Argumentation wären:
1. "schon" würde unterstellen, daß PHP älter ist als SSI, und
2. SSI ist im Webserver schon mit dabei, während PHP als separates
Produkt hinzu installiert werden muß.Viele Grüße
Michael-
Hallo,
Die beiden Schwachpunkte dieser Argumentation wären:
- "schon" würde unterstellen, daß PHP älter ist als SSI, und
diskutieren wir jetzt über die Schwachpunkter unserer (meiner) Argumentation oder über den Sinn und Nutzen von SSI? ;-)
- SSI ist im Webserver schon mit dabei, während PHP als separates
Produkt hinzu installiert werden muß.
Das ist richtig. Aber wenn PHP nunmal vorhanden ist (und PHP-Support ist ja selbst bei kostenlosem Webspace keine Seltenheit mehr), dann fragt man sich doch wo da der grosse Nutzen ist... doch eher in der Verwendung als "modulare Seitenelemente", zum Beispiel ein Menü oder immer wiederkehrenden Code.
Grüsse
Lactrik
-
-
-
-
-
-
-