Hi,

Ich kann aber gerne mal einen "komprimierten" PHP-Source veröffentlichen.
Das ist ja schon mal ein Problem, PHP? Ich dachte an eine HTML Seite.

Geht auch. Aber das händische Erstellen stumpfsinniger Framesets macht ab einer gewissen Site-Größe nicht wirklich Spaß! ;->

Besser ist es (ich schrieb es auch), man läßt so etwas popeliges automatisch erledigen. Nicht zuletzt: Ins Frameset soll ja der jeweilige BODY des Content-Frames (sowie TITLE, Description, Keywords, ...), damit Suchmaschinen das FS indizieren, und nicht den Frame. Und da spart es Arbeit, wenn man (wie bei der Arbeit ohne Frames) nur *eine* Quelle pflegen muß (ich habe es allerdings auch schon gemacht, daß das CMS dies alles regelt - ist halt eine Abwägungssache, was die Site sinnvollerweise zur Pflege braucht).

Wenn ich auf http://coding.binon.net/dhtml/index.htm gehe, müßte das Frameset nachgeladen werden und wenn das Frameset vorhanden ist, müßte ich die Unterseiten über das Memü bookmarken können, da muss wohl eher ein mod_rewrite Mechanismus eingebaut werden?

Ich schrieb schon mehrfach: Meine Coding-Site ist keine typische Website - auch keine (für mich) typische Frame-Website. Denn: Nicht der Text ist hier der Content, der Content ist, meinen alten Kisten ein virtuelles Denkmal zu setzen. D.h., hier sind ausnahmsweise die Framesets (also die verschiedenen "Desktops") *selbst* der "Content" (und deswegen auch der knallgrüne Desktop als Standard, und keiner der augenfreundlicheren anderen). Der Text ist nur der Honigtopf. O:-) Außerdem: Die Zielgruppe ist die der Webautoren (insbes. habe ich ja div. JS-Routinen), und nicht der Otto-Normalsurfer ...

Und nein: Daß man bei der Eingabe von http://coding.binon.net/dhtml/index.htm kein Frameset bekommt, ist Absicht. Denn auch wenn dieser URL zum Honigtopf zählt: Man soll trotzdem und immer eine Frameseite auch losgelöst vom Frameset anschauen können dürfen - selbst auf dieser Website. Wer anschließend das Frameset wieder haben möchte, muß diese explizit anfordern. Aber er muß ja nicht - er kann ja auch die kleine Navigation benutzen.

Was anderes ist es, wenn Du dem *Link* http://coding.binon.net/dhtml/index.htm folgst (von hier, von einer Suchmachine, von ...). *Dann* wird das (Standard-)Frameset nachgeladen.

Und zwar mittels JS (s. Zielgruppe).

Sollte der "Nachlade-URL" http://coding.binon.net/index.htm?dhtml/index.htm gebookmarkt oder weitergeben werden: Hier funktioniert das Nachladen dann auch ohne JS. Freundlich wie ich bin (;-)), verzichtet die Startseite auch von sich aus auf das Laden des Framesets, wenn der Surfer mit einem mobilen Client angedackelt kommt (sofern das Display nicht bekanntermaßen groß gennug ist). Bin ja kein Unmensch ... ;->

(Auch bei der normalen Nutzung läßt sich das Frameset per Links-Klick sprengen: Der Papierkorb schmeißt das Frameset quasi in den Müll, und der Perma-Link öffnet die jeweilige Content-Seite auch solo.)

Ich deute das so, das du wenn du von den nicht vorhandenen Nachteile sprichst, du damit immer eine dnaymische, "etwas umfangreiche" Seite meinst.

Sicher. Kleine Sites muß man IMHO nicht dynamisieren. Ab einer gewissen Größe (oder aufgrund anderer Umstände, z.B. Laie als Content-Pfleger), empfiehlt sich IMHO per se ein CMS.

Allerdings: So eine kleine Frameset-Engine in PHP ist wirklich nur wenige Zeilen lang! Ich habe für Sites, für die sich ein CMS nicht lohnt, auch eine "reine" FS-Engine geschrieben. Das Prinzip: Die FS-Engine wird als Error-Page-Handler angemeldet (oder auch via rewrite angesprochen). Findet sie zum (fehlgeschlagenen/umzulenkenden) Request einen Content-Frame, dann bastelt sie das zu diesem Content-Frame passende Frameset (passende Co-Frames, NOFRAMES-Bereich füllen, TITLE übernehmen, META-Description, ...). Findet sie keinen Content-Frame, wird ein Standard-Frameset mit dem passenden Error-Content erzeugt.

Das PHP-Script hat eine Dateigröße von 7KB in 160 Zeilen (inkl. Kommentaren, den diversen Fehlermeldungen in Deutsch & Englisch, sowie Loggen der (echten) Fehler nebst Benachrichtung des Webmaster per Mail (50% des Codes FS-Engine, 50% Error-Handler).

Nicht mit einberechnet ist dabei das FS-Template, sowie die Basis-Bibliothek, die ich in alle meine Scripts einbinde.

Also egal ob wir eine große Website (->CMS) oder eine kleine Website (->FS-Engine) machen sollen: Wenn der Kunde unbedingt Frames wünscht (und das kommt durchaus immer noch vor), dann kann er sie von uns ohne großen Zusatz-Aufwand bekommen, da alles schon längst existiert. Und zwar so, daß Suchmaschinen und Nutzer und Mitarbeiter gut damit klarkommen.

Das ist genau so ein Beispiel, wo ich mich diese Woche sehr geärgert habe. Die Seiten waren bis vor kurzem noch durchaus nutzbar (auch auf meinem alten Rechner mit einem 15" Monitor), trotz Frames. Als ich diese Woche mal dort was nachschauen wollte, ging fast gar nichts mehr, mein Monitor ist zu klein (17" mit einer 1024'er Auflösung):

Ja, das kann ich gut nachvollziehen. :-/

Klar hat meine Anwendung ein Menü und Systemelemente, aber ein Internetseite ist keine Anwendung,

Da mögen die Meinungen wohl auseinandergehen ... :-)

Gruß, Cybaer