frames ja oder nein?

[kalle1811]

was sagt ihr? findet ihr frames auf hp´s gut oder sch****?

[grakaman]

also ich persönlich finde sie scheisse :D
aber da gehen ja die geschmäcker weit auseinander...

mfg

[barracuda]

Originally posted by grakaman
also ich persönlich finde sie scheisse :D
/me too

[sun-man]

Hi,
persönlich finde ich Frames garnicht so übel.
Leider gibts aber einige Probleme z.B. mit Javamenüs die Frameübergreifend wirken sollen.
Naja, ich bastel mir gerade ne neue (Photo)Seite und probiere ohne Frames auszukommen. Dafür gibts jetzt endlich ein kleines (nicht unbedingt schönes) Javamenü.
Leider unterstützt mein Webspace kein PHP, damit ginge ein solcher Aufbau um ein vielfaches leichter....aber der Hoster gibt mir erst mit dem nächstgrößeren Paket PHP....nur brauche ich keine 200MB Webspace und auch kein MySQL.....

Wie auch immer.....ich würde es ohne Frames probieren, dann lieber auf Tabellen setzen.

MFG

[mictasm]

Ich bin auch für NEIN. Das hat zum einen optische Gründe, da manche Browser (Ns4.7, frühe Opera) vieles sehr merkwürdig anzeigen. Teilweise gibt es auch Zwischenräume, und die pixelgenaue Platzierung funktioniert meist nur in zwei Browsern. Dafür kann jeder die Frameset-Seiten extra aufrufen und Inhalte "klauen".
Ausserdem bin ich so langsam zum Tabellen-Fetischisten geworden. Und seit ich auf PHP gestossen bin, wird es eher noch schlimmer. Dafür habe ich nämlich mein Paket aufgestockt.

Ich benutzte trotzdem manchmal Frames, das hat dann aber meistens den Grund, dass ich bestimmte Sachen noch nicht weiss oder es einfacher ist. Für eine einfache Aufteilung (links-rechts, oben-unten) spricht auch nichts dagegen. Nur diese Verschachtelungen finde ich schrecklich.

MIC

[Loci]

Ich stimme da voll und ganz zu.Frames sind nun wirklich nicht schön.Aber leute wie ich zb. die kein PHP können sind da auf frames angewissen.
Schade das es keinen generator gibt, wie bei den frames *g*

[[F'sF.]Richy]

Originally posted by Loci
Ich stimme da voll und ganz zu.Frames sind nun wirklich nicht schön.Aber leute wie ich zb. die kein PHP können sind da auf frames angewissen.
Schade das es keinen generator gibt, wie bei den frames *g*

Jo des is schade, denn PHP ist schon feiner als Frames

[Loci]

Klar, aber leider net besonders noob freundlich :)

[Sen]

Ich finde, das es sehr auf die Seite ankommt, auf der Frames verwendet werden. Geht es nur darum, eine Seite aus mehreren Dateien zusammenzusetzen ist PHP auf jeden Fall besser.

Setzt man Frames sparsam aus Designgründen ein, sind sie für mich jedoch völlig ok. Manche Dinge lassen sich eben noch nicht vollständig mit einem Tabellenlayout lösen. Gerade, wenn ein Text in einem feststehenden Rahmen gescrollt werden soll, muss man noch auf Frames zurückgreifen, da die älteren Browser wie NS 4.x die CSS-Definition "overflow" oder I-Frames noch nicht unterstützen.

Sind diese älteren Browser irgendwann völlig von der Bildfläche verschwunden wird man auch kaum noch Frames benötigen.

[Kurgan]

als newbie hab ich auch mit frames rumgemacht ...aber mit php+html-tabellen sieht es besser aus, ist flexibler, und du sparst dir einen haufen darstellungprobs mit den diversen browsern

[kalle1811]

gibt es irgendwo eine seite, in der php für den noob einigermaßen verständlich erklärt ist?

[dagmundna]

Ich benütz keine Frames mehr, aber iframes. Bis ich endlich php kann... *nichtdurchblick*

[sun-man]

@dagmunda

Was issn das für'n Klops ???

<Haha, Dein Luschi-Browser checkt keine Frames!

Wenn ich auf diesen Check Deine Webseite antworten könnte würde ich dem Progarmmierer des Checks gehörig auf die Füssse treten. Jede normal Programmierte Frameseite funzt nämlich hervorragend mit meinem Browser......naja, so kann man Leute von der Seite auch fernhalten.

MFG

[dagmundna]

Originally posted by Mogul
@dagmunda

Was issn das für'n Klops ???

<Haha, Dein Luschi-Browser checkt keine Frames!

Wenn ich auf diesen Check Deine Webseite antworten könnte würde ich dem Progarmmierer des Checks gehörig auf die Füssse treten.

Muss ja wirklich ein Luschi-Browser, sein wenn er nen einfachen kleinen frame nicht checkt. ;D
Reg dich nicht auf, is ja nicht gegen dich gerichtet ;).
ne, im Ernst, ich hab das mit IE ab 4 und mit Netscape ab 5 getestet... sollte doch überall funzen???

[Matthias2x]

Originally posted by dagmundna
..., ich hab das mit IE ab 4 und mit Netscape ab 5 getestet... sollte doch überall funzen???

Netscape 5? Wo gabs den denn??

[mictasm]

Originally posted by dagmundna
Muss ja wirklich ein Luschi-Browser, sein wenn er nen einfachen kleinen frame nicht checkt. ;D


Sieht mir eher nach Luschi-Kommata aus...

MIC

[Sen]

Originally posted by dagmundna


Muss ja wirklich ein Luschi-Browser, sein wenn er nen einfachen kleinen frame nicht checkt. ;D ...

... ne, im Ernst, ich hab das mit IE ab 4 und mit Netscape ab 5 getestet... sollte doch überall funzen???

Frames können die meisten Browser, das stimmt ... aber iframes können nur Browser ab IE3 und NS 6.0 und wie das mit Mozilla und Opera aussieht weiss ich nicht.

Sen

[Kurgan]

Originally posted by dagmundna


Muss ja wirklich ein Luschi-Browser, sein wenn er nen einfachen kleinen frame nicht checkt. ;D
Reg dich nicht auf, is ja nicht gegen dich gerichtet ;).
ne, im Ernst, ich hab das mit IE ab 4 und mit Netscape ab 5 getestet... sollte doch überall funzen???

da liegst du aber falsch ...minimum zum testen ist ie 5 + 6, netscape 4.7x + 6, möglichst noch opera 5+6 und mozilla (mozilla weil das was da gut aussieht sieht überall zumindest annehmbar aus)

ach ja: alternative ist natürlich spzifikations konform coden :D

[Leonidas]

Bin prinzipiell gegen Frames. Wenn ich Deeplinks zu irgendwelchen Artiken auf Frameseiten setze, ist dann deren Hauptframe weg und nur der nackte Artikel zu sehen. Und Framenachlade-Scripte per Javascript sind nur eine halbe Lösung, weil nicht jeder Javascript an hat.

[KingLouis]

ich find frames eigendlich ziehmlich geil und praktisch. liegt aber warscheinlich daran, dass ich mit tabellen net klar komm und kein php kann;D

[Matthias2x]

Schonmal einer dran gedacht das Frames auch Traffic sparen können?! Dieser Tage konnte ich mal mit einer befreundeten Seite Infos diesbezüglich austauschen. So komme ich mit meiner Site (mit Frameset) auf ca. 500 - 900 MB Traffic täglich, die andere Seite hat minimum 1,3-1,7GB/Tag (Navigation, Seitenkopf etc. per PHP require() eingebunden) und das bei fast identischen Zugriffszahlen (Hits, Page-Impressions etc.). Es scheint so als ob sich die Browser doch nicht alles aus dem Cache holen. Natürlich haben Frames gewisse Nachteile, aber eben nicht nur. Vorallem ist es schwieriger über die Framegrenzen hinweg das Design ansprechend hinzubekommen, doch auch das ist lösbar.

[Kurgan]

Originally posted by Matthias2x
(mit Frameset) auf ca. 500 - 900 MB Traffic täglich, die andere Seite hat minimum 1,3-1,7GB/Tag (Navigation, Seitenkopf etc. per PHP require() eingebunden)

klar spart das traffic wenn man kein php kann ..mit require_once() wär das nicht passiert ...

[sun-man]

@Matthias2x

Ich hab wenig Ahnung von PHP, aber der Vergleich von 2 Seiten gefällt mir nicht wirklich. Ihr habt ungelogen, für meine Verhältnisse, Monstertraffic :) aber der Vergleich würde sich erst dann lohnen wenn es 2 identische Seiten, einmal PHP einmal HTML, wären.
Ich weiß nicht wie Ihr verglichen habt, aber jeden noch so kleine Bild oder nur ein Forumsklick erzeugt nunmal Traffic.

MFG

[Marcel]

Originally posted by Kurgan
klar spart das traffic wenn man kein php kann ..mit require_once() wär das nicht passiert ...

Sehr selbstsicher, die Aussage.
PHP läuft serverseitig; übertragen wird nur das von PHP generierte HTML. Und dem sieht man nicht an, mit wievielen PHP-Zeilen und wievielen includes es generiert wurde.

[Marcel]

Zum Unterschied Frames / Keine Frames:
Mal angenommen, eine Site hat ein festes Menü, mit 1kb HTML-Code. Dazu kommen im Schnitt 1kb mit Text, jeweils über die Menüpunkte abrufbar.

Fall 1: Frames
Beim ersten Laden des Frames wird das Menü einmal geladen. Danach nur noch die Texte. Bei 10 gelesenen Texten also 11 kb.

Fall 2: Keine Frames
Das Menü wird jedes Mal neu geladen, wenn ein Text neu geladen wird. Ich glaube nicht, dass ein Browser partielle HTML-Dateien cacht, er zieht also jedes Mal das Menü neu mit. Und schon wurden bei 10 Texten 20 kb übertragen.

Und nochmal: Bei der reinen Datenübertragung Server => Mein PC wird nur das HTML übertragen (womit auch wirksam das Sourcecode-Klauen verhintert wird). Ob, und wenn ja, wie, das HTML mit PHP generiert wird (ob Ihr z.B. die Zahlen von 1 bis 10 in einer Schleife oder mit 10 einzelnen fast identischen print-Befehlen ausgebt), ist für die vom Server auf meinen PC übertragene Datenmenge unerheblich. Gibt es einen Provider, der etwas anderes als diese Datenmenge (plus Rückkanal) als Traffic zählt?

Gruß,
Marcel

[Matthias2x]

Originally posted by Mogul
@Matthias2x

Ich hab wenig Ahnung von PHP, aber der Vergleich von 2 Seiten gefällt mir nicht wirklich. Ihr habt ungelogen, für meine Verhältnisse, Monstertraffic :) aber der Vergleich würde sich erst dann lohnen wenn es 2 identische Seiten, einmal PHP einmal HTML, wären.
Ich weiß nicht wie Ihr verglichen habt, aber jeden noch so kleine Bild oder nur ein Forumsklick erzeugt nunmal Traffic.

MFG

Mag sein das es erst für größere Seiten von belang ist, doch mein Kollege kommt mit dem Traffic schon über seine monatliche Freigrenze von 20 GB hinaus. Beide Seiten haben derzeit tägliche Besucherzahlen zwischen 2000 und 3000. An Spitzentagen auch mal um die 3500 (HP-URL siehe Sig.). Die Inhalte unterscheiden sich nicht allzusehr, und Grafiken werden auch relativ sparsam eingesetzt. Jedenfalls erklärt es nicht die doch immensen Unterschiede im Traffic. Übrigens PHP und Frames verbieten sich nicht, denn ich setze auch fast ausschließlich PHP ein, nur halt in einem Frameset. Im Prinzip hat Marcel schon recht, egal wieviel PHP-Code ich schreibe, letztendlich sieht der Browser nur den HTML-Quelltext + Bilder etc. und nur das wird übertragen.

[Matthias2x]

Originally posted by Kurgan
klar spart das traffic wenn man kein php kann ..mit require_once() wär das nicht passiert ...

Ich habs oben schon geschrieben, PHP und Frames schließen sich doch nicht gegenseitig aus oder...? Und was require_once() anbetrifft, ich mag es jetzt nicht mit letzter Sicherheit sagen, doch IMHO wird das Script bei jedem neuen Aufruf auch neu geparst, also wird auch die require_once() - Anweisung jedesmal neu ausgeführt, sonst machts doch gar keinen Sinn.

[x-dragon]

Da hab ich, als Hobby-Amateur-Webseiten-Bastler, doch mal spontan eine Frage. Kann man Tabellen ohne größere Probleme ineinander verschachteln? (z.B. mit Dreamweaver)

Wenn man z.B die Seite mal als Beispiel nimmt: http://x-dragon.bei.t-online.de (Menü, Gästebuch, Inhalt,... ist noch in Arbeit :) )

Bzw. macht es Sinn so eine Seite komplett auf Tabellen umzustellen? Ich möchte möglichst bei der Gestaltung recht flexibel bleiben, da noch nicht feststeht wie die Seite weiter ausgebaut wird.

[Kurgan]

Originally posted by Marcel


Sehr selbstsicher, die Aussage.
PHP läuft serverseitig; übertragen wird nur das von PHP generierte HTML. Und dem sieht man nicht an, mit wievielen PHP-Zeilen und wievielen includes es generiert wurde.


das ist korrekt ... und was glaubst wieviel traffic ein nicht generiertes html-dokument ausmacht ? :D

wenn auf ein require_once mit denied geantwortet wird, wird auch kein html übertragen sondern der client holt den krempel komplett aus dem cache. dementsprechend funzt das nur mit absolut statischen html-ausgaben

ps: hab ich selber nicht geglaubt, ist aber so. wir haben das mal mit ie und opera ausgemessen, jeweils hundert seitenaufrufe mit require und _once, sparte ca. 20% traffic, wobei das aber das absolute maximum sein dürfte, die seite war ja zum testen ausgelegt :D

[Matthias2x]

Originally posted by Kurgan
das ist korrekt ... und was glaubst wieviel traffic ein nicht generiertes html-dokument ausmacht ? :D
wenn auf ein require_once mit denied geantwortet wird, wird auch kein html übertragen sondern der client holt den krempel komplett aus dem cache. dementsprechend funzt das nur mit absolut statischen html-ausgaben


hmm und wo liegt da der Sinn wenn ich in der z.b. Navigation was ändere und keiner siehts...?

[Kurgan]

Originally posted by Matthias2x


hmm und wo liegt da der Sinn wenn ich in der z.b. Navigation was ändere und keiner siehts...?

dynamik, flexibilität, db ..und um beim thread zu bleiben: keine frames :-)

[Marcel]

Originally posted by Kurgan
das ist korrekt ... und was glaubst wieviel traffic ein nicht generiertes html-dokument ausmacht ? :D


Genausoviel wie ein generiertes, solange es dasselbe darstellt.
Einem Eimer Wasser ist es egal, ob das Wasser direkt aus dem Wasserhahn kommt oder aus dem Wasserhahn erstmal eingefroren und anschließend wieder aufgetaut wurde.

Originally posted by Kurgan
wenn auf ein require_once mit denied geantwortet wird, wird auch kein html übertragen sondern der client holt den krempel komplett aus dem cache. dementsprechend funzt das nur mit absolut statischen html-ausgaben


Reden wir eigentlich vom gleichen require_once? Ich spreche vom PHP-Befehl. Und der ist für den Browser absolut transparent, kann also auch nicht abgewehrt werden. Der require_once-Befehl wird vom PHP-Interpreter auf dem Server ausgeführt, sobald das Script, welches diesen enthält, abgearbeitet wird. Da wird der Browser nicht nach gefragt. Der Browser kann höchstens sagen, ob das gesamte Script abgearbeitet werden soll oder nicht. Er hat keine Ahnung davon, wie PHP auf dem Server die Seite zusammenbaut, er kann ja noch nicht mal PHP.

Originally posted by Kurgan
ps: hab ich selber nicht geglaubt, ist aber so. wir haben das mal mit ie und opera ausgemessen, jeweils hundert seitenaufrufe mit require und _once, sparte ca. 20% traffic, wobei das aber das absolute maximum sein dürfte, die seite war ja zum testen ausgelegt :D

Der Versuch interessiert mich jetzt. Was genau habt Ihr wie gemessen?


Um es nochmal klar herauszustellen, der Unterschied zwischen require() und require_once() wirkt sich erst aus, wenn ein PHP-Skript zwei verschiedene andere Skripte einbindet, wovon eines das andere auch wieder einbindet.

Gruß,
Marcel

[Matthias2x]

Originally posted by Kurgan
dynamik, flexibilität, db ..und um beim thread zu bleiben: keine frames :-)

Also entweder reden wir aneinander vorbei oder ich versteh hier was falsch. Weiter oben schreibst du noch die Sache macht nur Sinn mit absolut statischen HTML (also nix mit Dynamik)und jetzt schreibst du was von Dynamik und Flexibilität. Und was bitte hat das ganze mit einer DB zu tun...? Lies dir mal die Beschreibung zu require_once() im PHP-Manual durch, denn was da steht hat mit dem was du schreibst absolut nix zu tun:


Die require_once()-Anweisung ersetzt sich selbst durch die angegebene Datei (ähnlich der C-Preprozessor-Anweisung #include), funktioniert also ähnlich wie die require()-Anweisung. Der Hauptunterschied dazu liegt in der Tatsache, dass bei require_once() der einzubindende Code genau einmal in das Skript eingefügt wird.

Sie erzeugen beispielsweise die folgenden zwei Include-Dateien utils.inc und foolib.inc: Beispiel 12-2. utils.inc

<?php
define(PHPVERSION, floor(phpversion()));
echo "GLOBALE SIND GUT\n";
function guterTee() {
return "Oolong-Tee schmeckt gut!";
}
?>


Beispiel 12-3. foolib.inc

<?php
require ("utils.inc");
function zeigeVar($var) {
if (PHPVERSION == 4) {
print_r($var);
} else {
var_dump($var);
}
}

// es folgen weiter Funktionen ...
?>


Nun schreiben Sie ein Skript cause_error_require.php: Beispiel 12-4. cause_error_require.php


<?php
require("foolib.inc");
/* das Folgende erzeugt einen Fehler */
require("utils.inc");
$foo = array("1",array("complex","quaternion"));
echo "dies erfordert utils.inc, das auch\n";
echo "in foolib.inc erforderlich ist\n";
echo "Aufruf von guterTee: ".guterTee()."\n";
echo "Ausgabe foo: \n";
showVar($foo);
?>


Wenn Sie letzteres starten, wird folgende Ausgabe erzeugt (gilt für PHP 4.01pl2):


GLOBALE SIND GUT
GLOBALE SIND GUT

Fatal error: Cannot redeclare causeerror() in utils.inc on line 5



Durch Umschreiben von foolib.inc und cause_errror_require.php (Gebrauch von require_once() statt require()) und Umbenennung des letzten Skriptes zu avoid_error_require_once.php haben wir nun: Beispiel 12-5. foolib.inc (fixed)

...
require_once("utils.inc");
function showVar($var) {
...


Beispiel 12-6. avoid_error_require_once.php

...
require_once("foolib.inc");
require_once("utils.inc");
$foo = array("1",array("complex","quaternion"));
...


Beim nachfolgenden Aufruf wird folgende Ausgabe erzeugt (bei PHP 4.0.1pl2):

GLOBALE SIND GUT
dies erfordert utils.inc, das auch
in foolib.inc erforderlich ist
Aufruf von guterTee: Oolong-Tee schmeckt gut!.
Ausgabe foo:
Array
(
[0] => 1
[1] => Array
(
[0] => complex
[1] => quaternion
)

)

[Unregistered]

frames sucken

[Kurgan]

Originally posted by Marcel


Genausoviel wie ein generiertes, solange es dasselbe darstellt.
Einem Eimer Wasser ist es egal, ob das Wasser direkt aus dem Wasserhahn kommt oder aus dem Wasserhahn erstmal eingefroren und anschließend wieder aufgetaut wurde.



naja, der vergleich hinkt etwas ...der eimer hat nämlich keinen cache :D


Reden wir eigentlich vom gleichen require_once? Ich spreche vom PHP-Befehl. Und der ist für den Browser absolut transparent, kann also auch nicht abgewehrt werden. Der require_once-Befehl wird vom PHP-Interpreter auf dem Server ausgeführt, sobald das Script, welches diesen enthält, abgearbeitet wird. Da wird der Browser nicht nach gefragt. Der Browser kann höchstens sagen, ob das gesamte Script abgearbeitet werden soll oder nicht. Er hat keine Ahnung davon, wie PHP auf dem Server die Seite zusammenbaut, er kann ja noch nicht mal PHP.


das ist jetzt aber nicht nett ..klar reden wir vom gleichen befehl und es ist auch nicht so als wenn ich noch nie was mit php zu tun gehabt hätte ..
es geht ja auch nicht darum was der client mitbekommt, sondern was der server liefert ..bei einem bereits ausgeführtem script (das require_once wird ja dann nicht mehr ausgeführt) liefert der server aber anscheinden nix, und der client (der ja nix neues bekommt) holt sich den kram aus dem cache


Der Versuch interessiert mich jetzt. Was genau habt Ihr wie gemessen?

ich hab jetzt verzweifelt nach diesem blöden ding gesucht, hab sogar meinen alten server reaktiviert in der hoffnung was zu finden ..nüx, kollege hatte auch nix mehr davon, war ja auch bloss ein test ..

gemessen wurde folgendes: 2 identische seiten mit wiederholten tabellenaufbau, eine seite reines html, die andere aus einem php-script generiert, demtenstprechend nur 15 zeilen code etwa.
beides auf einen w2k-server unter apache (zu dem zeitpunkt aktuelle version, ist etwa 18 monate her) aufgerufen , jeweils 100 mal mit ie und 100 mal opera, gemessen wurde mit auf dem server installiertem trafficmonitor 3.irgendwas (nicht soooo wahnsinnig genau, reicht aber für den zweck). ich weiss noch das die differenz ziemlich 20% betrug


Um es nochmal klar herauszustellen, der Unterschied zwischen require() und require_once() wirkt sich erst aus, wenn ein PHP-Skript zwei verschiedene andere Skripte einbindet, wovon eines das andere auch wieder einbindet.

Gruß,
Marcel

nö, stimmt nicht: ein require wird IMMER ausgeführt wenn die entsprechende zeile dran ist, ein require_once wird egal wie oft die zeile drankommt (neu laden klicken oder selbstaufruf oder sonstwas) in jedem fall nur EINMAL ausgeführt ..sagt ja auch schon die übersetzung: require = benötigt, once = einmal

wenn ich mal zeit hab werd ich den versuch nochmal rekonstruieren und wiederholen ...

[Kurgan]

Originally posted by Matthias2x


Weiter oben schreibst du noch die Sache macht nur Sinn mit absolut statischen HTML (also nix mit Dynamik)und jetzt schreibst du was von Dynamik und Flexibilität. Und was bitte hat das ganze mit einer DB zu tun...?



jain: dabei ging es um die trafficersparnis durch require_once gegenüber include + require und dies ist in der tat nirgends beschrieben ..
der grundsätzliche vorteil von html-erzeugendem php-scripten gegenüber reinem html liegt eben in der dynamik, flexibiltät und anbindung von db´s. da aber php nur html an den client schickt, ist da natürlich kein unterschied zu sehen ..ausser am link :D

allerdings drängt sich bei mir so langsam der verdacht auf, das wir damals irgenwas falsch gemacht haben und die 20% weniger schlicht messfehler/logikfehler darstellt ..

[Marcel]

Originally posted by Kurgan
naja, der vergleich hinkt etwas ...der eimer hat nämlich keinen cache :D


Ich erweiter das Beispiel mal um jemanden, der irgendwo sitzt und Durst hat. Zu dem werden die Eimer hingetragen. In diesem Beispiel wäre der Cache eine große Wanne, die bei diesem Durstigen steht und in das das Wasser aus den Eimern gekippt wird.

Originally posted by Kurgan
das ist jetzt aber nicht nett ..klar reden wir vom gleichen befehl und es ist auch nicht so als wenn ich noch nie was mit php zu tun gehabt hätte ..


Ich wollte Dir nicht vor den Kopf stoßen, ich wollte nur sichergehen, dass wir nicht aneinander vorbei reden. Meine Kenntnisse sind, was Skriptsprachen für Web-Server betrifft, nämlich auf PHP und ein wenig Python begrenzt. Hätte ja sein können, dass Du von Perl oder ASP und sonstigem MS-Skript-Kram oder so sprichst, wo sowas anders läuft.

Originally posted by Kurgan
es geht ja auch nicht darum was der client mitbekommt, sondern was der server liefert ..bei einem bereits ausgeführtem script (das require_once wird ja dann nicht mehr ausgeführt) liefert der server aber anscheinden nix, und der client (der ja nix neues bekommt) holt sich den kram aus dem cache


Wenn aber eine Seite erneut aufgerufen wird, so wird auch das require_once erneut aufgerufen. Nur dann eben bei diesem Ausführen nur einmal.
Beispiel:
Skript A.php required Skript B.php und Skript C.php. B.php required ebenfalls C.php.

Bei require:
A.php wird ausgeführt, B.php wird reingenommen, darüber auch C.php, und C.php dann aus A.php nochmal. Soweit ist ja alles bekannt.
Wird A.php erneut aufgerufen, passiert dasselbe. Da kann kein clientseitiger Cache der Welt reinreden.

Bei require_once:
A.php wird ausgeführt, B.php wird reingenommen, darüber auch C.php, und C.php dann aus A.php nicht nochmal, weil wurde über B.php ja schon. Auch soweit ist alles bekannt.
Wird A.php erneut aufgerufen, passiert wieder dasselbe. A.php nimmt B.php, B.php nimmt C.php, A.php nimmt C.php kein zweites Mal. Auch hier kann kein clientseitiger Cache der Welt reinreden.

Was ich mit diesem Beispiel sagen will: Beim zweiten Aufruf des Skriptes A.php durch den Browser auf Client-Seite wird genausoviel Skript ausgeführt wie beim ersten Aufruf, auch, wenn require_once genutzt wird. require_once wirkt innerhalb einer vom Browser angestoßenen Skriptausführung (des Skriptes A.php), nicht über mehrere Aufrufe von A.php durch den Browser.
Reden wir an diesem Punkt vielleicht aneinander vorbei?

Originally posted by Kurgan
ich hab jetzt verzweifelt nach diesem blöden ding gesucht, hab sogar meinen alten server reaktiviert in der hoffnung was zu finden ..nüx, kollege hatte auch nix mehr davon, war ja auch bloss ein test ..

gemessen wurde folgendes: 2 identische seiten mit wiederholten tabellenaufbau, eine seite reines html, die andere aus einem php-script generiert, demtenstprechend nur 15 zeilen code etwa.
beides auf einen w2k-server unter apache (zu dem zeitpunkt aktuelle version, ist etwa 18 monate her) aufgerufen , jeweils 100 mal mit ie und 100 mal opera, gemessen wurde mit auf dem server installiertem trafficmonitor 3.irgendwas (nicht soooo wahnsinnig genau, reicht aber für den zweck). ich weiss noch das die differenz ziemlich 20% betrug


Hm, aber in einem Punkt sind wir uns einig, es wird bei jedem Aufruf, der vom Browser nicht gecachet wird, die komplette Tabelle vom Server übertragen, egal, ob statisch, mit PHP/require oder PHP/require_once?

Originally posted by Kurgan
nö, stimmt nicht: ein require wird IMMER ausgeführt wenn die entsprechende zeile dran ist, ein require_once wird egal wie oft die zeile drankommt (neu laden klicken oder selbstaufruf oder sonstwas) in jedem fall nur EINMAL ausgeführt ..sagt ja auch schon die übersetzung: require = benötigt, once = einmal

wenn ich mal zeit hab werd ich den versuch nochmal rekonstruieren und wiederholen ...

Zur Übersetzung: Jou, die Frage ist, auf welchen zeitlichen Rahmen das "einmal" begrenzt ist.

Gruß,
Marcel

[Kurgan]

Originally posted by Marcel


Ich erweiter das Beispiel mal um jemanden, der irgendwo sitzt und Durst hat. Zu dem werden die Eimer hingetragen. In diesem Beispiel wäre der Cache eine große Wanne, die bei diesem Durstigen steht und in das das Wasser aus den Eimern gekippt wird.

schon besser :D

Ich wollte Dir nicht vor den Kopf stoßen, ich wollte nur sichergehen, dass wir nicht aneinander vorbei reden. Meine Kenntnisse sind, was Skriptsprachen für Web-Server betrifft, nämlich auf PHP und ein wenig Python begrenzt. Hätte ja sein können, dass Du von Perl oder ASP und sonstigem MS-Skript-Kram oder so sprichst, wo sowas anders läuft.

hab ich auch nicht so aufgefasst, klang bloss so :-)
von python+perl hab ich null ahnung, und von :kotz: asp wär es mir lieber wenn ich davon noch wie was gehört hätte ..so ein schrott, winzigweich halt .. java kann ich auch besser als php :D

Wenn aber eine Seite erneut aufgerufen wird, so wird auch das require_once erneut aufgerufen. Nur dann eben bei diesem Ausführen nur einmal.

ich glaub da ist dein denkfehler: das require_once könnte man vom sinn her auch übersetzen mit: kopier an diese stelle datei.xyz , und das wird nur einmal gemacht ..

Beispiel:
Skript A.php required Skript B.php und Skript C.php. B.php required ebenfalls C.php.

Bei require:
A.php wird ausgeführt, B.php wird reingenommen, darüber auch C.php, und C.php dann aus A.php nochmal. Soweit ist ja alles bekannt.
Wird A.php erneut aufgerufen, passiert dasselbe. Da kann kein clientseitiger Cache der Welt reinreden.

Bei require_once:
A.php wird ausgeführt, B.php wird reingenommen, darüber auch C.php, und C.php dann aus A.php nicht nochmal, weil wurde über B.php ja schon. Auch soweit ist alles bekannt.
Wird A.php erneut aufgerufen, passiert wieder dasselbe. A.php nimmt B.php, B.php nimmt C.php, A.php nimmt C.php kein zweites Mal. Auch hier kann kein clientseitiger Cache der Welt reinreden.

ne, genau das eben nicht: wen a.php erneut aufgerufen wird, steht a.php noch im speicher ..mit eben den "hineinkopierten dateien" b+c !

Was ich mit diesem Beispiel sagen will: Beim zweiten Aufruf des Skriptes A.php durch den Browser auf Client-Seite wird genausoviel Skript ausgeführt wie beim ersten Aufruf, auch, wenn require_once genutzt wird. require_once wirkt innerhalb einer vom Browser angestoßenen Skriptausführung (des Skriptes A.php), nicht über mehrere Aufrufe von A.php durch den Browser.
Reden wir an diesem Punkt vielleicht aneinander vorbei?

jo, glaub schon. ist natürlich ne frage des aufbaus und da ich meist mit session-id arbeite wird zumindest in dem fall bei erneutem aufruf von a.php nichts hineinkopiert, da steht dann nämlich im grunde kein require_once mehr sondern stattdessen die datei.xyz




Hm, aber in einem Punkt sind wir uns einig, es wird bei jedem Aufruf, der vom Browser nicht gecachet wird, die komplette Tabelle vom Server übertragen, egal, ob statisch, mit PHP/require oder PHP/require_once?

jup, 100%ack

Zur Übersetzung: Jou, die Frage ist, auf welchen zeitlichen Rahmen das "einmal" begrenzt ist.

wie gesagt, session handler


Gruß,
Marcel

es scheint halt so zu sein, das ich den browser-cache quasi "fern-animieren" kann loszulegen ..