Nur teile einer Website aktualisieren

[Cybaer]

Hi,

Oh Mann, natürlich ist es Mehraufwand das sagst du in den erwähnten thread doch selber mehrmals:

Nein, das ist IMHO eine Frage der Professionalität, wie man an Projekte rangeht. Gehen wir mal durch:

1. Inkompatibilität zu manchen Browsern.
   Nein. Für Nicht-Frame-Browser wurde NOFRAMES definiert. Faulheit des Autors sollte man nicht der Technik vorwerfen. ;->
   Faulheit Mehraufwand zu betreiben, oder? (einen noframes Bereich zu erstellen)

Nein, Faulheit selbst die gewählte Technik (hier Frames) unzureichend (also nicht gemäß den Standards) umzusetzen. Ist IMHO genauso, als wenn man mit JS & W3C-DOM arbeitet, nicht auf die Existenz von document.getElementById abfragt (ist ja auch ein Mehraufwand) und sich dann beschwert, daß der NN4 Fehler meldet.

Generell gilt IMHO, daß man jede über HTML hinausgehende Technik aus Kompatibilitätsgründen "sauber" (also rückwärtskompatibel) einarbeiten sollte. Das gilt für JavaScript, intensivem Einsatz von CSS (was, unbedacht eingesetzt, die Seiten auf Browsern ohne/mit abgeschaltetem CSS ziemlich übel aussehen lassen kann) und eben auch Frames (oder Flash, Java, ...). Also kein "Mehraufwand", sondern "systemimmanent".

(Anmerkung: Andererseits sollte/darf man durchaus auch "vorausschauend" arbeiten: Noch zu verabschiedende/bereits verabschiedete HTML-Tags/-Attribute habe ich bei Bedarf (und rückwärtskomptibel) stets verwendet, selbst wenn es noch gar keinen Browser gab, der dies unterstützt hat (gleiches gilt heute z.B. auch für CSS Level 3).)

Davon abgesehen, kann diese "Systemimmanenz" natürlich möglichst einfach, aber auch möglichst umfangreich implementiert werden (je nach Art des Projekts und den Anforderungen).

Beispiel:
AFAIR habe ich zum ersten Mal mit dem NN3 Frames eingesetzt (im Zuge des Relaunches eines E-Commerce-Site). Da ich von Anfang an (logischerweise und heutzutage bei größeren Projekten ja auch üblich) ein CMS benutzt habe, wurde der NOFRAMES-Bereich automatisch ebenfalls mit dem Content gefüllt, während der Inhaltsframe von der Suchmaschinenindizierung ausgenommen wurde.

Folge: Die Suchmaschinen indizierten die Framesets, Besucher via AltaVista & Co. bekamen dann, je nach Fähigkeit ihres Browsers, die passende Seite.

Mehraufwand: Null
Ergebnis: Optimal

3. Kein Bookmarken von Unterseiten möglich.
   Niemand zwingt den Autor, Unterseiten zu verwenden. Ebenso ist es möglich, für jede Seite ein eigenes Framest zu erstellen (oder es automatisch generieren zu lassen).
   Aha, also kein Mehraufwand (für jede Seite ein eigens Frameset zu erstellen bzw. ein skript in jede Seite einfügen)?

S.o. Außerdem: Scripts, die mehrfach vorkommen, werden eh extern gehalten. =:-o

Im obigen Fall wurden die FS' vom CMS (also automatisch) erstellt.
Das ist, insbesondere mit PHP, nun auch wirklich kein Problem mehr.

Im Falle von JS-Framesets, kann man die Generierung ebenfalls in ein externes Script auslagern, welches das FS ggf. erzeugt.

Im einfachsten Fall ist die FS-Seite ein Template (bis auf wenige Parameter stets gleich), welches bei Erstellen der Hauptseite auf Knopfdruck generiert wird.

Das alles ist, zumal gemessen am Aufwand größerer Sites, wirklich kein Mehraufwand. Bei kleineren ("Hobby"-)Sites stellt sich das Problem IMHO gar nicht erst (mangels echter Masse und Charakter der Arbeit).

4. Kein direktes Verlinken von Unterseiten möglich.
   Doch, durchaus. Wenn du das als Autor allerdings universell machen willst (und nicht für jeden Anker ein eigenes FS erstellen möchtest), dann muß das Frameset allerdings dynamisch generiert werden, den Hash auslesen und in die FS-Definition integriert werden.

Kein Mehraufwand?

Nein. 2-Zeiler in JS, Perl und/oder PHP rechne ich nicht als Mehraufwand. =:-) Das ist es vielleicht für jemanden, der noch nie programmiert hat und Google nicht bedienen kann, um nach fertigen "Lösungen" zu suchen. ;-> Solche Leute bezeichnen sich auch nicht als "Web-Designer" (außer, sie arbeiten für Werbeagenturen >;->).

Ich für meinen Teil mache einfach das, was ich immer mache: Ich binde einen fertigen Zweizeiler ein und das war's mit dem "Mehraufwand".

und so geht deine Argumentation weiter. Selbst wenn es für dich einfach ist, dann ist es halt einfacher zusätzlicher Aufwand der ohne Framesets nicht entstehen würde.

Natürlich ist alles was über HTML 1 hinausgeht sogesehen "zusätzlicher Aufwand". Vergleichen muß man es aber vielmehr mit dem Aufwand, den man alternativ betreiben müßte, um das zu erreichen, was man erreichen wollte (falls das überhautp geht). Die *Differenz* zw. diesen beiden Anstrengungen, ist der "Mehraufwand"! Nicht der (systemimmanente) Aufwand als solches.

Und wenn der Mehraufwand sinnvoll ist gibt es auch nichts gegen Frames zu sagen, trotz allem bleiben die Nachteile bestehen.

Also zumindest die in der Liste genannten "Nachteile" erweisen sich bei genauerer Betrachtung (und bei korrekter Anwendung der Technik), als "nicht existent". Übrig bleibt der vermeintliche "Mehraufwand" (von manchen "Workarounds" genannt), der, vernünftiges Herangehen an an solches Projekt (unabhängig von den tatsächlich verwendeten Techniken) und sicherlich auch Erfahrung (ebenfalls bei jeder Technik mehr als sinnvoll) vorausgesetzt, gar nicht "mehr" sein muß.

Wenn ich hingegen gedanken- und kreativlos an Projekte herangehe, dann artet aber natürlich alles(?!) in Mehraufwand aus (ebenfalls unabhängig von den eingesetzen Techniken). Dies jedoch nicht zu tun, ist die Aufgabe eines guten Web-Designers. Z.B.:

• Nachhaltigkeit der Struktur ("cool URLs don't change" & Erweiterbarkeit)
• Bestmögliche Bedienung
• Auswahl der dafür zu nutzenden Techniken nebst kompetenter Umsetzung

Wenn ich da an mein erstes Web-Projekt denke (Standard-Browser war der Mosaic 2.0 - Netscape och eine "Nullnummer"), dann habe ich bereits damals (und als Anfänger/HTML-Autodidakt) die Site so geplant (die logische Struktur der Inhalte/Artikel war bereits vorher von den Verantwortlichen - in langen Sitzungen - festgelegt worden), daß

• jeder Daten einpflegen kann (CMS)
• automatische Datenübernahme aus bestehenden Datenbeständen möglich ist (CGI)
• offline-kompatible psychische Datenstruktur und damit potentielle Möglichkeit der Offline-Nutzung (inkl. Online-Verbindungs-/Aktualisierungsmöglichkeit) - was später sogar tatsächlich gemacht wurde (auf Messen ohne Netzanschluß und als Offline-Produktkatalog für Händler und Kunden als Ersatz für den zu dick gewordenen Print-Katalog), aber auch problemlose Indizierung der gesamten Site (inkl. aller Produktseiten) durch Suchmaschinen.
• ggf. erhöher Komfort für Anwender (JS - kam nachträglich mit NN2, Schnelladevariante CMS & CGI)
• Maximum an Komptibilität (alle Browser auf allen Systemen - da gab es deutlich mehr als heute), zumal mit Blick auf die inhomogene Zielgruppe (Studenten und Lehrkräfte: von langsamen PCs mit <=14.4er Modems und Uralt-Browsern der Marke "einmal eingerichtet, nie aktualisiert, bis Top-PCs mit Standleitung und der aktuellsten Navigator beta)

Alle weiteren Verbesserungen ließen sich problemlos innerhalb dieses Rahmens erdenken und umsetzen.

Das (Vor-)Urteil einiger (Hobby-)?Web-Designer, die, ggf. noch etwas grün hinter den HTML-Ohren, vielleicht mit dieser oder jener Technik nicht so umgehen (können/möchten) wie es sein sollte, ist für mich hingegen kein Beleg für irgendwas ...

... dafür bin ich schon zu lange dabei, habe schon zu viele "haarsträubende" Umsetzungen von vermeintlichen Profis gesehen und schon zu viele "offene Münder" bei Leuten, die auf manche Idee erst gar nicht gekommen sind ...

Gruß, Cybaer