nicht angemeldet
Moin!
das warten allerdings geht nicht nur mit onload, zumindest wüsste ich nicht, wie. ich muss ja irgendwas im onload machen, damit es im eigentlichen ablauf wieder weitergehen kann.
[...]
statt des interval timers könnte ich natürlich eigentlich auch die funktion durch das onload wieder aufrufen lassen. ok, ich glaub, jetzt hab ichs, was du gemeint hast ;-)
Exakt. Und das geht sogar noch schöner, weil es wirklich nur dann etwas tut, wenn etwas anderes fertig geworden ist.
NEIN! das war nur vereinfacht, um nicht den ganzen code reinzuschreiben, wie üblich ;-) rest s.o., es ging darum, im HINTGERGRUND (also ohne ein neues fenster aufzumachen, oder das aktuelle neu zu laden) daten aus der seite (wie immer sie dahin kommen, z.b. aber auch durch usereingabe) in eine datenbank einzutragen.
Das "wie immer sie dahin kommen" ist aber durchaus sehr interessant für die Aufgabenstellung.
Insofern möchte ich meine zweite Aussage "Mach soviele Daten wie geht in _eine_ URL rein" immer noch. Es spart dir Zeit in der Ausführung, hat eine höhere Performance, etc.
vielleicht gibt es aber eine elegantere lösung, serverskripte im hintergrund zu starten, als diese. (ich habs auch mit document.script[0].src=... versucht, aber das geht nicht (wie auch das beispiel in selfhtml http://127.0.0.1/SelfHTML/javascript/objekte/htmlelemente.htm#script dazu zumindest im ie6 nicht richtig funkt. da kommt bei mir beim ersten mal auf englisch klicken die deutsche variante)
Du kannst URL-Parameter an den Server schicken, indem du Bilder austauschst. Sollte im Prinzip simpel gehen, indem du wie gehabt die document.images[...].src austauschst. Das PHP-Skript schickt dann einfach ein Redirect auf ein existierendes (dafür vorgesehenes) Bild, und gut ist. Wahlweise kann es natürlich selbst Bilddaten ausgeben.
ausserdem bleibt eine frage offen: so wie in der ursprünglichen version hat doch wohl die while schleife ohne inhalt die aktualisierung des iframe und v.a. die ausführung der enthaltenen skripte blockiert. sehe ich das richtig? sonst hätte die schleife ja auch mal beendet werden müssen, wenn sich zwischenzeitlich die abbruchbedingung geändert hat.
Es sieht jedenfalls ganz stark so aus. Deshalb: Warteschleifen kann man dann mit while programmieren (bzw. einem Äquivalent dazu), wenn man die Prozessorpower nicht für was anderes braucht, weil man sich in einem Single-Task-System befindet. Moderne Rechner machen aber Multi-Tasking - da ist es einfach nur frech und böse[tm] gegenüber den restlichen Tasks, wenn man beim Warten ständig nachguckt, ob's schon soweit ist. Event-gesteuert (onload etc.) läßt sich das Ganze viel schöner machen. Erstens geht dir der Event nicht durch die Lappen, sondern wird garantiert abgearbeitet. Hättest du nämlich einen sehr schnellen Prozess, der deine Prüfvariable kurz auf wahr und dann wieder auf falsch setzt, und deine Prüfschleife hat in der Zwischenzeit keinen Zugriff gehabt, dann merkst du das Ereignis nicht. Und (was eben noch viel wichtiger ist): Wenn du über ein Event auf ein Ereignis wartest, verbrauchst du keine Rechenzeit für dieses Warten. Diese Rechenzeit steht anderen Tasks zur Verfügung.
- Sven Rautenberg
Diese Signatur gilt nur am Freitag.