nicht angemeldet
Hallo Christoph,
Daher weiß ich nicht genau, was der IIS _prinzipiell_ bereitstellt.
ich würde als Arbeitshypothese annehmen, daß er SSI kann, nicht aber XSSI.
<div id="name">
<!--#include file="datei.htm" -->
</div>
Hoppla. Du willst ein vollständiges HTML-Dokument (mit <html> usw.) in ein <div> einbinden?
Welcher Dokumenttyp soll Deiner Meinung nach dabei herauskommen?
Außerdem ist "include file" laut Apache-Dokumentation deprecated.
Und da gehts dann los. Mein Apache weigert sich, ein HTML-Dokument einzubinden, obwohl ich exakt so verfahren bin, wie in der Apache-Dokumentation beschrieben.
Was bedeutet das im Klartext? "Geht nicht" geht nicht.
Fehlerbeschreibung, bitte - inklusive eventueller Fehlermeldungen aus dem error_log.
Ich kann und will meine HTML-Dokumente natürlich nicht mit einer "falschen" Extension versehen, weil sie auch einzeln, also als eigenständige Dokumente, aufrufbar bleiben sollen ...
Genau das bezweifele ich eben - daß Du ein vollständiges HTML-Dokument in ein <div>-Tag eines HTML-Dokuments includen darfst und als Ergebnis wieder ein korrektes HTML-Dokument bekommst.
Du hast gar keine andere Wahl, als einen Schnipsel zu includen - und den kannst Du dann problemlos mit einer anderen Endung versehen.
Willst Du diesen Schnipsel "alleine" auch verwenden, dann brauchst Du eine zweite SSI-Datei, die eine dafür angepaßte Umgebung erzeugt und ebenfalls diesen Schnipsel includet.
Ich mache das auf meiner Homepage schon lange so - damit realisiere ich die parallele Navigation mit und ohne Frames: Das, was in der Frames-Variante im Arbeits-Frame als Startseite (die selbst wiederum ein SSI-Dokument mit minimalem eigenen Inhalt ist) geladen wird, ist in der frameslosen Variante in den <body> des Frameset-Dokuments eingebettet.
Vergleiche
http://www.schroepl.net/frameset.shtml?unten
mit http://www.schroepl.net/noframes.shtml;
der gemeinsame Include-Schnipsel dazu ist
http://www.schroepl.net/_updates.inc.
Und dann: Meine HTML-Dokumente haben alle eine DOCTYPE-Angabe, zwei meta-tags, einen Header-Bereich usw. Das heißt, ich habe unter Umständen mehrere Dutzend (immer dieselben) DOCTYPE-Angaben, die bereits auf dem Server in einer "großen" Datei zusammengeklebt werden und auch so beim Browser ankommen
Eben - genau das ist das Problem.
Was Du willst, das geht einfach nicht (so). Die HTML-Köpfe müssen raus aus den Include-Schnipseln - folglich können letztere keine vollständigen HTML-Dokumente sein.
Das einzige, was mir bisher eingefallen ist, wäre, sämtliche HTML-Dokumente vor dem Includieren erst durch ein Perl-Script aufrufen zu lassen, das die "überflüssigen" Auszeichnungen entfernt.
Das ist doch viel aufwändiger, als zwei SSI-Dateien zu halten.
Mein Apache möchte es gerne in der Form
<!--#include virtual="daten.xml" -->
haben, dann gehts prima. Aber der IIS bei meinem Provider zeigt da gar nix an, der möchte zwingend
<!--#include file="daten.xml" -->
Willkommen in der Welt der proprietären Webserver. Es hat schon seinen Grund, warum man zum Testen exakt denselben Webserver lokal verwenden muß und nicht irgendeinen.
Was glaubst Du, was mir alles um die Ohren fliegen würde, wenn meine Seiten auf einem IIS lägen, der kein .htaccess kann? Weia ...
Bleibt mir wirklich nix andres übrig als mit einer "if"-Abfrage über "SERVER_SOFTWARE" den grade aktiven Server zu ermitteln?
Verwende einfach denselben Webserver, dann hast Du Dein Problem nicht.
Oder löse die SSIs client-seitig auf (per Programm, vor dem Hochladen), dann hast Du auf dem Server nur noch statisches HTML. So mache ich das bei einigen meiner Seiten (u. a. weil gzip_cnc statische Seiten komprimieren kann, dynamische aber nicht).
Macht das überhaupt Sinn, aich so eine "SSI-Konstruktion" auszudenken?
Entsteht dabei ein Dokument, das Dein Besucher als sinnvoll ansehen würde?
Ich habe ein Dokument mit 309 KB (eine komplette Release-Historie einer 15 Jahre alten Software) auf meiner Domain liegen - weil der Besucher in diesem Dokumenten mit Cntrl-F suchen könnte, wenn er wollte (z. B. um herauszufinden, in welchem Release ein bestimmtes Feature eingebaut wurde). Es wäre viel umständlicher für den Benutzer, etwas zu finden, wenn ich dieses Dokument in viele Dateien zerlegen würde - man könnte nicht mal besser navigieren, aber deutlich schlechter suchen.
Aber wenn ich jetzt nur 30 Stück davon includiere, werden sie ja alle bereits auf dem Server zusammengeklebt und im Browser dargestellt, was dazu führt, daß die Anzeige des "Quelltextes" der im Browser angezeigten Gesamtdatei schnell mal eine Größe von 1 MB und mehr erreichen kann.
Und? Kann der Anwender dieses Dokument brauchen oder nicht?
Die Forums-Hauptdatei ist ja auch relativ groß - aber niemand käme auf die Idee, sie aus Performance-Gründen zu zerteilen, weil das bekanntlich die Usability verschlechtern würde.
Das ist lokal natürlich kein Problem, aber online mag ich mir ja nicht erst 1 MB runtersiehen müssen, selbst mit meiner DSL-Verbindung nicht.
Je generischer Dein HTML-Code ist, um so besser wäre der Komprimierungsfaktor via gzip:
xxx.xxx.xxx.xxx - - [30/Jan/2003:19:26:14 +0100] "GET /kurslisten/inhalt/idx2.pl?idx=16966&xslanguage=en HTTP/1.1" 200 4744 "-" "Mozilla/5.0 (rv:1.3a)" "SHARK=CLIENT%3DFXSENG%3B+USER%3Dms%3B+CONN%3D11%3B" "-" "gzip" DECHUNK:OK 99962 -> 4744 = 96 Prozent
Und ja, das _ist_ sehr schlechter HTML-Code - weil es in Netscape 4 funktionieren muß. :-(
Viele Grüße
Michael
T'Pol: I apologize if I acted inappropriately.
V'Lar: Not at all. In fact, your bluntness made me reconsider some of my positions. Much as it has now.