nicht angemeldet
Hallo Leute,
ich bin dabei Christine's MenueScript (CKMENUE Version
1.2 04/98) nachzuvollziehen und nachzuempfinden.
Zunächst klappte das Meiste auch ganz gut, bis es
darum ging das Menue dynamisch an 'Useraktionen'
anzupassen. Ab da habe ICH nur noch systematisch viele,
schöne, bunte GPFs und Postmortems produziert.
Das Originalscript läuft anstandslos!
Um das zu verstehen, lasst mich kurz rekapitulieren:
Christine baut zunächst einen FRAMESET auf in dem sich
auch ein leeres Frame befindet welches dann das Menue
aufnehmen soll. Den Inhalt generiert sie aus einer
tabellarischen Beschreibung per JavaScript vermittels
write()-Anweisungen. Die Funktion die das beim ersten
Aufruf bewerkstelligt wird durch das onLoad-Event des
FRAMESET-Tags aufgerufen. Sie heißt function zeigen(AF).
Aus dem MenueFrame können Funktionen im HEAD des FRAMESETs
aufgerufen werden um das Menue an die 'Useraktionen' anzu-
passen. Diese rufen schlußendlich dann wieder die Funktion
function zeigen(AF) auf, die das MenueFrame mit der nun
angepassten Menuefassung überschreiben.
Bei Christine heißen diese Funktionen function mach_auf(ind)
und function mach_zu(ind) und rufen beide die Funktion
function zeigen(AF) auf.
Zunächst war ich ratlos was die GPFs anbetraf und habe die
Syntax immer wieder überprüft. Dann habe ich mir Christine's
Script zum x-ten Mal zu Gemüte geführt, bis ich über Anwei-
sungen am Ende ihrer mach_...funktionen gestoßen bin. Dort
steht jeweils: setTimeout('zeigen(self.MenueFrame)', 300);
Sie fügt also eine Wartezeit von ca. 1/3 Sekunde ein, bevor
das Menueframe wieder auffrischt. Entgegen ihren löblichen
Gewohnheiten waren diese Statements ausnahmsweise nicht
kommentiert. ;-((
Künstliche Verlangsamung wollte ich doch eigentlich nicht
einbauen. Aber was hat Christine sich dabei gedacht?
Nachdem ich das abgekupfert hatte, waren die GPFs weg! ;-))
Aus meinen wilden Hardwarezeiten kannte ich sowas ja wenn
Signallaufzeiten einfach nicht so wollten wie ich. Da haben
mal ein oder auch mehrere Ferritperlchen oder auch ein paar
Gatter herhalten müssen um meinen Pfusch geradezubügeln.
Aber gibt es sowas hier auch?
Wenn ich Christine's Kunstgriff richtig verstehen sollte,
dann ist nicht gewährleistet, daß der aufrufende Job
<A HREF="javascript:... abgeschlossen ist bevor die
zeigen()-Funktion das Frame wieder überschreibt!
Typischer Fall also von 'sich selbst den Stuhl unterm
Hintern wegziehen'?
Was Software anbelangt, hatte ich doch mal was von Semaphoren
gelernt. Das scheint für Javascript nicht zu gelten!?
Oder zumindest in diesem Zusammenhang nicht.
Ist das Überhaupt etwas was man einem Interpreter abverlangen
darf? Oder sollte man das doch eher in den Bereich der
(persönlichen) Kunstfertigkeit und Geschicklichkeit beim
Programmieren zurechnen? Auf die Nebenwirkungen und Seiten-
effekte wird eigentlich bei jeder Programmiersprache hingewiesen!
Tja, und wenn ich eine Prozedur überschreibe die noch nicht
abgeschlossen ist, dann fall ich halt auf den Bauch.
Meine bisherigen Statements sind wohl zu platt um an die
Sache heranzukommen, also, was ist da los?
Aus dem MenueFrame wird die Auffrischung per <A HREF...
ausgelöst. Aber was ist ein solcher Anker?
Funktional ist das primär wohl ein JUMP, ein GOTO.
Wirklich? Irgendwie habe ich mal gesehen, daß man einem
Anker auch noch sagen kann (return) ob er denn auch wirklich
springen soll. Also dann doch kein bedingungsloser Jump.
Aber wie funktioniert dieser Mechanismus?
Muß ich wohl doch noch mal meinen Hosenboden befragen.
So, nun steht aber im HREF noch ein JS-Funktionsaufruf
drin. Und, von Funktionen erwarte ich doch schon rein
prinzipiell, daß sie einen Mechanismus zur Wertrückgabe
enthalten. Der Anker DARF also garnicht einfach so
wegspringen. Wie war das noch mit dem Stuhl?
Christine's 300 ms sind sicher nur eine irgendwie geartete
Peilung, vermutlich erwachsen aus Frust und Erfahrung.
Der Erfolg gibt ihr recht, und, es weist daraufhin, daß
Browser diesen Konflikt wohl per Zeitverzögerung lösen.
Zu unserer Bequemlichkeit.
Das Ganze ist nur eine Vermutung, aber es wäre schon eine
Erklärung für so manche (erlittene) Surfüberraschung.
Es ist wohl eine vertrackte Sache an die ich bislang noch
nicht gedacht hatte.
Aus Erfahrung wird man (vielleicht und hoffentlich) klüger.
Das gilt natürlich nicht für alle Browser in gleichem
Maße, und dürfte auch vom Rechner und dem Betriebssystem
abhängen. Aber sage mir ja keiner ich bräuchte nur das/den
XYZ nehmen und sei alle Sorgen los! Glaub' ich nicht mehr.
Und wenn einer unserer Cracks behaupten sollte bei
seinen Scripts könne sowas nicht vorkommen, tja,
dann sollte ich wohl mit Wattebäuschen odgl schmeißen.
Mir ist diese Erfahrung schon was wert und ich werde wohl
etwas anders darüber denken wenn ich mir eine Site ansehe
und mir schmiert meine Kiste unvermittelt wieder ab.
Das Ganze gibt mir einiges nahrhaftes für den Grips mit
auf den Weg. Nicht nur programmtechnisch.
Das Testen und die Aufmerksamkeit werden intensiver werden.
Letztlich erhöht die Entdeckung dieser beiden Statements
in Christine's Scripts aber meine Hochachtung für sie und
stärkt mein Vertrauen in ihre Expertise.
Klaus
PS: am 22. abends offline geschrieben, vor Stefans
entsprechenden Bemerkungen. Ich kann aber auch nicht
ausschließen, daß er auch solche Postings mit seinen
Wettereien meint. Werde es sehen.