Vorschlag fuer Feature-Artikel zu Includes

[Alexander Foken]

Moin Moin !

Flüchtigkeitsfehler:

In "Active Server Pages (ASP)" fehlt etwas: "Die Syntax in >>> <<< gleicht der von SSI auf dem Apache-Webserver:"

In "Missverständisse und Anfänger-Fragen" würde ich Bezug groß schreiben, schlag besser mal im Duden nach: "Häufige Missverständnisse/Newbie-Fragen in >>>bezug<<< auf Includes:"

Unter "Serverseitige Lösungen" fehlt im Text "Etwas völlig anderes ist der Begriff "DHTML"" der Link auf das DHTML-Kapitel von SelfHTML.

Meiner Meinung nach benutzt Du zu viel "ss" und zu wenig "ß", aber auch da solltest Du mal im Duden nachsehen.

Inhalt:

Wann setzt man welche Technik ein? Die Entscheidung, ob man serverseitige Tools oder HTML-Editoren einsetzt, hängt sicherlich auch davon ab, ob man serverseitige Tools einsetzen darf.

Setzt man HTML-Editoren ein, muß bei einer einzigen Änderung an einer zentralen Include-Datei unter Umständen die gesamte Webseite neu "berechnet" und hochgeladen werden. Das passiert bei serverseitigen Tools natürlich nicht.

Wenn man serverseitige Tools einsetzen will, welches soll man benutzen? Kriterien für die Auswahl (Performance, Serverbelastung, Flexibilität, Wartbarkeit, Portierbarkeit, ...)?

"Kann ich auch Seiten, die auf einem anderen Server liegen, als Include einbinden?" Soweit ok, es fehlt allerdings ein Hinweis auf die Sicherheit. Gerade diese Frage kommt im Forum immer wieder mal vor, hauptsächlich um PHP-Code von anderen Servern einzubinden. Wie gefährlich es sein kann, Code von fremden Servern ohne weitere Prüfungen auszuführen, wurde im Forum oft genug diskutiert.

In "SSI - Server Side Includes" schreibst Du "Meist funktionieren sie automatisch in Dateien mit der Endigung .shtml, bei manchen Server-Konfigurationen auch bei Dateien auf .html." SuSE konfiguriert(e) den Apachen so, evtl. auch andere. Leider hat dies einige üble Seiteneffekte, die Du nicht erwähnst: Der Apache muß *jede* ausgelieferte HTML-Seite parsen, auch wenn das gar nicht notwendig ist. Das kostet Leistung. Die Trennung in *.html und *.shtml reduziert die unnötige Last. In "alten Zeiten" gab es den X-Bit-Hack (siehe Apache-Doku, existiert sowohl in 1.3 als auch in 2.0), der anhand des Executable-Bits der Datei entschied, ob die Datei stumpf ausgeliefert oder geparst wurde. Das ist - wie der Name schon sagt - ein Hack, den man besser nicht benutzt.

In "Weitere serverseitige Programmiersprachen" schreibst Du zu ColdFusion "Cold Fusion Markup Language (CFML) ist eine Technologie von Macromedia, die auf >>>speziell ausgerüsteten Webservern<<< läuft." Diese "spezielle Ausrüstung" ist eine Installation von ColdFusion, das sich ähnlich wie PHP in den Webserver einhängt (soweit ich weiß, nur in IIS und Netscape / iPlanet).

Formulierungen / Ausdruck:

"Seitenbastler" in "Includes als Frames-Ersatz" ist abwertend, "Newbie" kann ebenfalls als abwertend empfunden werden.

In "Missverständisse und Anfänger-Fragen" schreibst Du dreimal ">>>kriegt nicht mit<<<", da ist "merkt nicht", "kann nicht unterscheiden", ö.ä. besser.

In "Beispiel: Fusszeile" schreibst Du als letztes Codebeispiel:

<!-- Ende des Inhalts -->
<!-- Platzhalter/Befehl für fusszeile.inc -->
</body>
</html>

Weil die Syntax für den Include-Befehl je nach Technik sehr unterschiedlich ist, würde ich das anders darstellen:

<!-- Ende des Inhalts -->
*** Befehl um fusszeile.inc einzubinden ***
</body>
</html>

Die Zeile "*** Befehl um fusszeile.inc einzubinden ***" würde ich andersfarbig und/oder kursiv und/oder in einer anderen Schriftart darstellen.

In "Weitere serverseitige Programmiersprachen" schreibst Du ">>>Offenbar<<< gilt für Includes folgende Syntax:". Du bist Dir also nicht sicher, ob diese Syntax richtig ist? Warum liest Du dann nicht in dem von Dir angegebenen Referenz-Link nach?

2. Bei den serverseitigen Programmiersprachen sage ich bis jetzt
   kein Wort zu Perl. Erstens kenne ich mich damit zuwenig aus,
   zweitens bezweifle ich, dass es geeignet ist fuer blosse Includes
   (AFAIK existiert keine Syntax, mit der man Perl-Code mitten
   in den HTML-Code einstreuen kann wie z.B. PHP oder SSI),

Es gibt diverse Techniken, um mit Perl HTML zu erzeugen, z.B. mit embperl, entweder eingebunden in mod_perl (schneller) oder in einem Perl-CGI.

und drittens befuerchte ich, dass dann staendig Newbies
bei mir (als Autor) oder hier im Forum nachfragen, warum ihre
Perl-Skripten nicht funktionieren, und man ihnen dann ASCII-Upload,
CHMOD und den ganzen Krempel 1000 mal erklaeren muss...

Das könntest Du gleich im Artikel ein für alle mal klären, das hätte außerdem den angenehmen Seiteneffekt, daß solche Fragen im Forum schlicht mit einem Link auf Deinen Artikel "abgewürgt" werden können. Bleibt anzumerken, daß die großen "Volkshoster" für billige Webpräsenzen in der Regel kein Perl anbieten, weil es zu mächtig ist. Wenn überhaupt, dann nur für CGIs, nicht als mod_perl. PHP läßt sich wohl leichter soweit kastrieren, daß ein böser User nicht gleich den ganzen Server lahmlegt. Auf dedizierten oder virtuellen Servern (nicht zu verwechseln mit Vitual Hosts; zu erkennen am root-Zugriff) sieht die Sache schon anders aus.

Im Ernst: Falls jemand denkt, dass auch Perl als "Include-Sprache"
geeignet ist und mir den notwendigen Code und/oder Links zu
guten Tutorials schickt, ergaenze ich den Artikel gerne...

Eine schnelle Google-Suche liefert u.a. http://www.quiptime.de/site/perl/embperl/embperl_faq.php und http://perl.apache.org/embperl/. Embperl funktioniert auch offline, quasi als Konkurrenz zu HTML-Editoren.

Fuer groessere Bloecke mit Quellcode ist folgendes vorgeschrieben:

<table width="100%" cellpadding=10><tr><td class="xmpcode" bgcolor="#ffffe0"><pre>
<html>
<!-- irgendwas. Bitte auch hier alle HTML-eigenen Zeichen maskieren -->
</html>
</pre></td></tr></table>

Ich finde diesen Quellcode graesslich:

• Voellig ueberfluessige Tabelle
• presentational Markup (width, cellpadding, bgcolor)

Richtig.

• keine logische Auszeichnung als Programmcode.

Doch: pre

Folgendes faende ich viel sauberer:

<p class="xmpcode"><code>
<html><br>
<!-- irgendwas. Bitte auch hier alle HTML-eigenen Zeichen maskieren --><br>
</html><br>
</code></p>

Meine Meinung: Nimm <pre> statt <code>+<br>, dafür ist es IMHO da. Du kannst gerne eine Klasse zuweisen, um es zu stylen.

Allerdings bin ich nicht für die Artikel verantwortlich, da sollen andere einen verbindlichen Kommentar abgeben.

Die Links habe ich an den jeweiligen Stellen im Fliesstext eingebaut.
Eine extra Linkliste am Schluss scheint mir in diesem Fall nicht
sinnvoll/notwendig.
Gibt es dazu andere Meinungen?

Ja. Es ist SelfHTML-Stil, und es erlaubt den schnellen Überblick über Seiten mit weiteren Informationen, ähnlich wie eine Quellenangabe in wissenschaftlichen Texten.

Alexander