nicht angemeldet
Hallo emu,
Weil Du es in [pref:t=67153&m=386251] gewuenscht hast,
beschreibe ich hier, was ich in der aktuellen Version
des Artikels
http://www.tiptom.ch/homepage/includes.html
gegenueber der ersten Version
http://www.tiptom.ch/homepage/includes0.html
u.a. aufgrund Deiner Kritik geaendert habe.
"Includes" sind HTML-Bausteine, die an einer einzigen Stelle gespeichert sind, aber an mehreren Orten verwendet werden.
Das ist durchaus nicht notwendig.
Es ist mir voellig klar, dass man auch eine "leer Huelle"
machen kann, in die man dann mit SSI oder dergleichen
eine vollstaendige HTML-Datei einbindet, so wie Du es tust.
Die "normale", gaengige Anwendung von Includes, die ich
beschreiben moechte, ist aber eben gerade, dass man
HTML-_Bausteine_ einbindet und _nicht_ vollstaendige
HTML-Dateien.
Und ueblich ist auch, dass man ein Include mehrmals
verwendet, sonst ist es IMHO normalerweise sinnlos,
Includes zu verwenden.
(Abgesehen eben von Sonderfaellen wie bei Dir,
wo je nach Bedingung der eine oder ander Baustein
eingebaut wird.)
Ich habe den Satz geaendert.
Neu heisst es:
| "Includes" sind HTML-Bausteine, die an
| einer einzigen Stelle gespeichert sind,
| aber an mehreren Orten verwendet werden können.
^^^^^^
Das Aktualisieren geschieht auf Webserver oder bereits auf dem Rechner des Autors.
Welches Aktualisieren? Das ist eine sehr schwammig Formulierung, über die sogar ich, der zumindest nicht Anfänger ist, lange nachdenken musste.
Diesen Satz habe ich ersatzlos gestrichen.
Stattdessen habe ich den Text unter
"Beispiel - Fusszeile"
um folgende Abschnitte ergaenzt:
| Durch den Include-Mechanismus wird später an der
| Stelle des Platzhalters/Befehls der HTML-Baustein
| aus der entsprechenden Datei (fusszeile.inc) eingefügt.
| Dieser Prozess kann entweder noch auf dem Rechner
| des Autors geschehen (siehe Abschnitt "Lösungen mit
| HTML-Editoren") oder aber auf dem Webserver
| (siehe Abschnitt "serverseitige Lösungen").
Auch, wenn es meiner und vermutlich deiner Meinung nach unverantwortlich ist, Javascript-»Includes« zu verwenden, diese Möglichkeit zu leugnen, ist nicht sehr schlau.
Ich habe einen entsprechenden Hinweis im letzten Teil
"Missverstaendnisse und Anfaenger-Fragen" gemacht
unter
| Funktionieren Includes mit Browser XY?
| [...]
| (Browserabhängige - und somit schlechte und
| sehr unzuverlässige - "Alternativen" zu Includes
| wären das HTML-Element <iframe> sowie einige
| JavaScript-Konstrukte.)
Wichtig: Includes dürfen nicht vollständige HTML-Seiten sein, sondern nur Bausteine. Es wäre völlig falsch, eine vollständige HTML-Datei als Include in eine andere einzubetten. Denn somit hätte man im endgültigen Quelltext die Elemente [...] doppelt.
Verquere Logik, siehe mein Gegenbeispiel.
Siehe oben, Dein "Gegenbeispiel" ist eben gerade
nicht ein klassisches Beispiel fuer Includes.
Du hast nur eine "leere Huelle" und bindest dort
zufallsgesteuert eine vollstaendige HTML-Datei ein.
Wenn jemand so weit ist, dass er sowas realisieren
will und kann, braucht er hoffentlich meinen
Artikel nicht mehr. Oder dann ist er hoffentlich
genug intelligent, um darauf zu kommen, dass,
wenn er eine vollstaendige Datei einbetten will,
die Huelle "leer" sein muss, also nur gerade
den Include-Befehl, aber nicht auch noch
<html>, <head> und <body> enthalten darf.
Ich habe den mittleren Satz geaendert, um Deiner
(selbstgenannten) Pedanterie gerecht zu werden:
Es wäre völlig falsch, eine vollständige HTML-Datei
als Include in eine andere vollständige Datei einzubetten.
[DHTML]
Kombination von HTML, CSS und JavaScript, also von Dingen, die den Browser/Client betreffen.)
Ich will nicht darauf hinweisen, dass Javascript theoretisch auch auf dem Server laufen kann,
Jetzt uebertreibst Du es aber IMHO mit Genauigkeit
und Vollstaendigkeit.
Da versuchen wir den Newbies Tag fuer Tag klar zu machen,
dass JavaScript auf dem Client laeuft und deshalb "boese"
und unzuverlaessig ist.
Und nun kommst Du mit so theoretischen Moeglichkeiten
wie serverseitigem JavaScript.
Das werde ich im Artikel nicht erwaehnen; es wuerde
IMHO nur Verwirrung stiften und hilft niemandem etwas.
aber deine Definition von DHTML ist schlicht falsch, siehe auch andere Wortmeldungen dazu.
Ich habe den Absatz geaendert. Jetzt lautet er so:
| [Dynamische Webseiten] [...]
| (Etwas völlig anderes ist der Begriff Dynamisches
| HTML - "DHTML". Darunter versteht man die Kombination
| von HTML, JavaScript und oft auch CSS. "Dynamisch"
| bedeutet hier: Mit JavaScript werden *im Browser*
| gewisse Inhalte der Seite verändert oder ausgetauscht,
| nachdem der Webserver die Seite an den Browser
| ausgeliefert hat. Diese Effekte setzen aber voraus,
| dass der Browser den JavaScript-Code versteht und ausführt.)
Kannst Du mir eine bessere Definition in ein paar Saetzen liefern?
Bei kommerziellem Webspace sollte es meiner Meinung nach selbstverständlich sein, dass SSI, PHP oder andere serverseitige Programmiersprachen zur Verfügung stehen, [...]
Deine persönliche Meinung ist, pardon, irrelevant für diesen Artikel.
OK, Du hast recht.
Ich habe diesen Satz gestrichen.
Stattdessen habe ich geschrieben:
| In der Leistungsbeschreibung Ihres Webspace-Providers (Webhosts)
| sehen Sie, ob Ihnen SSI, PHP oder andere serverseitige
| Technologien/Programmiersprachen zur Verfügung stehen.
Seien wir ehrlich - einer der meistgenannten Gründe, warum so viele Seitenbastler überhaupt Frames verwenden, ist Bequemlichkeit.
[...] Deine Polemik (»Seien wir ehrlich« - an wen richtest du dich denn eigentlich, an den Anfänger oder an Experten?) hat in einem Feature-Artikel nichts zu suchen, höchstens kannst du versuchen, sachlich auf die Probleme hinzuweisen.
Der "seien wir ehrlich" Satz war schlecht, ich habe ihn gestrichen.
Anstatt die Nachteile von Frames zu wiederholen, habe ich den Link
zum Artikel von Michael Nahrath (subotnik) an den Anfang des
Abschnitts "Includes als Frames-Ersatz" gestellt.
Egal, ob die Navigation in einem <DIV>-Element, in einer Tabellenzelle oder einfach in einer Fusszeile plaziert ist - in allen Fällen reicht ein Include-Befehl/-Platzhalter [...]
Auch noch auf diese Diskussion willst du dich in deinem Artikel einlassen. Ich werde dich nicht daran hindern, bitte dich aber, das etwas fundierter zu tun.
Ich beispielsweise rate dringend von <div> ab, ebenso wie von Tabellen. Von Frames sowieso.
In meinem Artikel geht es um Includes.
In dem Abschnitt geht es darum, dass man
auf Frames verzichten kann.
Wo die Leute dann in ihrem neuen Layout die
Navigation hinpacken, ist mir persoenlich egal.
Wenn Du es schaffst, Deine Seiten ohne Layouttabellen
und ohne ein einziges DIV zu gestalten, dann ziehe
ich vor Dir den Hut.
Hast Du mal ein paar Beispiele, fuer optisch ansprechende
Seiten, die auch eine etwas komplexere Navigation
enthalten als nur gerade 5 Links, und die ohne DIV und
Layouttabelle auskommen? (Die Seiten muessen natuerlich
nicht von Dir sein - wenn ja, umso besser! ;-)
In meinen Augen ist es schonmal ein Fortschritt,
wenn jemand auf Frames verzichtet und halt noch
_eine_ Layout-Tabelle einsetzt, um links die
Navigation und rechts den Inhalt zu haben.
Es ist nunmal nicht jedermanns Sache, sich
stundenlang mit CSS und der lausigen Browser-
Umsetzung davon mit intensiven Tests auseinander-
zusetzen.
Ich will ganz sicher nicht in diesem
Artikel auch noch die Diskussion
Layout-Tabelle vs. DIV-Layout vs. "weder noch",
(was Dir offenbar als beste Loesung vorschwebt)
wiederkaeuen.
Ich will nur zeigen, dass alle diese Loesungen
mit Includes moeglich sind.
Ich habe folgende neue Saetze in dem Abschnitt:
| In den einzelnen HTML-Seiten steht an der Stelle,
| wo später die Navigation sein soll, der
| Platzhalter/Befehl, um den Baustein einzubinden.
| Dabei spielt es keine Rolle, ob die Navigation
| "einfach so" als HTML-Block im normalen Fluss
| des Dokuments vorkommt (wie z.B. die Fusszeile
| im obigen Beispiel), oder ob sie in einem <DIV>-Element
| oder in einer Zelle einer Layout-Tabelle plaziert ist.
Auf der zusaetzlichen Seite mit den zwei
ausfuehrlicheren Beispielen habe ich jetzt
ein Beispiel, wo direkt die UL-Liste mit
der Navigation mit CSS positioniert wird (kein DIV),
und ein anderes Beispiel mit einer Layout-Tabelle:
http://www.tiptom.ch/homepage/includes2.html
Beim Beispiel mit der Layout-Tabelle
http://www.tiptom.ch/homepage/includes2.html#layouttabelle
weise ich noch kurz darauf hin, dass dieses
nicht der "reinen Lehre" entspricht.
Zudem verlinke ich dort auf das SelfHTML-Kapitel
"Tabellen als Mittel für Web-Seitenlayouts"
http://selfhtml.teamone.de/html/tabellen/layouts.htm
Wenn schon wuerde ich von diesem Kapitel
eine vollstaendige Eroerterung der Problematik
von Layout-Tabellen erwarten.
mitkriegen
[...] einfach nur Umgangssprache [...], [...] in einem technischen Artikel nicht adäquat [...]
Danke - es war mir nicht bewusst, dass dies ein Helvetismus ist.
Ich habe alle Formulierungen mit "mitkriegen" geaendert.
Ich liste nicht alle Fehler und offensichtliche Missverständnisse auf, [...]
Schade, dann bleiben sie naemlich drin... ;-)
Wie Du jetzt hoffentlich siehst, habe ich mir
Deine Kritik zu Herzen genommen, so gut ich konnte,
und ich danke Dir noch einmal fuer Dein ausfuehrliches
Feedback.
Wenn Du den Artikel noch immer pauschal "unbrauchbar"
findest, aber mir nicht sagen kannst, woran das liegt,
dann ist mir damit leider nicht sehr geholfen.
Ich habe den Artikel jetzt mal den Devs zur Beurteilung
geschickt und warte jetzt auf ihre Antwort.
Natuerlich nehme ich gerne auch hier im Forum weiterhin
Kritik, Ergaenzungen und Verbesserungsvorschlaege entgegen,
insbesondere zum Vergleich der serverseitigen Technologien,
der noch immer sehr lueckenhaft ist.
Freundliche Gruesse
Thomas