nicht angemeldet
Fenster speichern
0 0 
Der Martin
0
0
Fenster speichern
Hallo
if (cName=='AUFTRAG') {
AufWin = window.open('',cName,'fullscreen=yes,scrollbars=yes,resizable=yes');
AufWin.focus ();
Kann man den Inhalt der var AufWin irgendwie speichern ? Ich möchte nach dem Logout die offenen Fenster wieder zumachen.
Gruss Horst
-
Moin,
Kann man den Inhalt der var AufWin irgendwie speichern ? Ich möchte nach dem Logout die offenen Fenster wieder zumachen.
Wenn du kein "var" vor die Variable schreibst, ist es eine globale. Mein Test funktioniert jedenfalls.
<body> <script type="text/javascript"> function oeffne() { AufWin = window.open('http://test.de'); AufWin.focus(); } </script> <a href="javascript:oeffne();">Öffnen</a><br /> <a href="javascript:AufWin.close();">Schließen</a> </body>Grüße Marco
-
Hallo,
Kann man den Inhalt der var AufWin irgendwie speichern ?
es liegt in der Natur einer Variablen, einen Wert zu speichern.
Wenn du kein "var" vor die Variable schreibst, ist es eine globale. Mein Test funktioniert jedenfalls.
Ja, du hast die Frage anscheinend genauso verstanden wie ich.
Ob wir richtig liegen? Keine Ahnung. Klingt mir zu einfach.<a href="javascript:oeffne();">Öffnen</a><br />
<a href="javascript:AufWin.close();">Schließen</a>Und bitte zeig so einen Unfug wie das Verstümmeln von Umlauten nicht auch noch als Musterlösung. Das sollte bestenfalls ein Notbehelf für kaputte Umgebungen sein und sich ansonsten auf die Zeichen beschränken, bei denen das in HTML erforderlich ist: &, < und meinetwegen, der Symmetrie wegen, noch >.
Ciao,
Martin--
Lieber eine Stumme im Bett, als eine Taube auf dem Dach.
Selfcode: fo:) ch:{ rl:| br:< n4:( ie:| mo:| va:) de:] zu:) fl:{ ss:) ls:µ js:( -
<a href="javascript:oeffne();">Öffnen</a><br />
<a href="javascript:AufWin.close();">Schließen</a>^^^^^^^^^^^
Seit wann schreibt man das wieder so? Das war zu meiner Zeit (also weit im letzten Jahrtausend) schon pfui ....-
<a href="javascript:AufWin.close();">Schließen</a>
^^^^^^^^^^^
Seit wann schreibt man das wieder so? Das war zu meiner Zeit (also weit im letzten Jahrtausend) schon pfui ....Was ist daran falsch?
Mathias
-
Was ist daran falsch?
Wenn sich das in den letzten Jahren nicht geändert hat, ist das immer noch nicht STandardkonform. Desweiteren gehört in href="" eune URL und kein Script.
Und nur so nebenbei: Pfui != falsch (zumindest nicht zwingend)
Also nichts rauslesen, was da nicht steht. Wenn ich definiv wüsste, dass es nicht erlaubt ist, hätte ich das geschrieben, dass es mieser Stil ist, ist seit vielen Jahren bekannt.Wie gesagt, vor einigen Jahren war es explizit falsch, aber es wäre nicht das erste mal, dass etwas schlechtes, nur weil es verbreitet ist, zum Standard wird.
-
Wenn sich das in den letzten Jahren nicht geändert hat, ist das immer noch nicht STandardkonform. Desweiteren gehört in href="" eune URL und kein Script.
»javascript:«-URLs werden in HTML5 standardisiert.
http://dev.w3.org/html5/spec/webappapis.html#javascript-protocolWenn ich definiv wüsste, dass es nicht erlaubt ist, hätte ich das geschrieben, dass es mieser Stil ist, ist seit vielen Jahren bekannt.
Warum ist es mieser Stil? Wie sieht das Schließen eines per JavaScript geöffneten Popup-Fenster in gutem Stil aus?
Das Einbetten von JavaScript ins HTML, besonders über Inline-Event-Handler, ist allgemein schlechter Stil, ja. Im Falle einer Funktionalität, die nur bei aktiviertem JavaScript existiert und sichtbar ist, kann man einen »javascript:«-Link aber ohne Probleme verwenden. Siehe auch diese Diskussion.
Das Problem von »javascript:« ist mehr, dass der Code im globalen Kontext ausgeführt wird, was eine Kapselung, die bei richtigem Event-Handling möglich wäre, verunmöglicht. Beim Öffnen und Schließen von Popups ist das aber ein kleineres Problem – die Referenz auf das window-Objekt des Popups über den globalen Scope zugänglich zu speichern, hat mehr Vorteile.
Zur Zugänglichkeit von Popup-Fenstern auch ohne JavaScript habe ich einen gesonderten Artikel verfasst.
Mathias
-
Moin,
Wenn sich das in den letzten Jahren nicht geändert hat, ist das immer noch nicht STandardkonform. Desweiteren gehört in href="" eune URL und kein Script.
"javascript:..." IST eine URL. Ich habe kein Skript in das href-Attribut geschrieben.
Diese konkrete Schreibweise <http://de.selfhtml.org/javascript/sprache/regeln.htm#namen@title=finde ich übrigens auch in der SelfHTML-Dokumentation> immer wieder»javascript:«-URLs werden in HTML5 standardisiert.
http://dev.w3.org/html5/spec/webappapis.html#javascript-protocolOk, ich wusste nicht, dass es vorher nicht standardisiert war.
Wenn ich definiv wüsste, dass es nicht erlaubt ist, hätte ich das geschrieben, dass es mieser Stil ist, ist seit vielen Jahren bekannt.
Warum ist es mieser Stil? Wie sieht das Schließen eines per JavaScript geöffneten Popup-Fenster in gutem Stil aus?Das hätte ich dann auch gern mal gewusst. Manchmal hat man direkt das Gefühl, dass für viele Leute hier nur der Stil gut ist, den sie selbst verwenden bzw. sich angeeignet haben. Viele Wege führen nach Rom, und nicht alle sind schmutzige Trampelpfade.
Das Einbetten von JavaScript ins HTML, besonders über Inline-Event-Handler, ist allgemein schlechter Stil, ja.
Allerdings muss man auch beachten, dass das ein einfacher Beispieltest für mich war, um das Problem nachzuvollziehen. Was du beschreibst ist ja im allgemeinen schlechter Stil, da es, wenn es komplexer wird, unschön zu warten ist. Wenn man allerdings nur ein kleines 3-Zeilen-Javascript auf der gesamten Seite hat, ist es IMHO eher sinnlos dafür extra noch eine Datei einzubinden.
Grüße Marco
-
Hi,
Wenn man allerdings nur ein kleines 3-Zeilen-Javascript auf der gesamten Seite hat, ist es IMHO eher sinnlos dafür extra noch eine Datei einzubinden.
JavaScript-Code muss ja nicht unbedingt über externe Ressourcen eingebunden werden.
Ein kleiner Script-Schnippsel kann auch erst mal als direkter Inhalt eines SCRIPT-Elements im HEAD oder am Ende von BODY eingebunden werden.Was du beschreibst ist ja im allgemeinen schlechter Stil, da es, wenn es komplexer wird, unschön zu warten ist.
Die Erweiterungen, die irgendwann mal vorgenommen werden sollen, sind zum jetzigen Zeitpunkt vielleicht noch gar nicht abzusehen.
Dann aber über das ganze Dokument verstreutes „inline“-JavaScript in Attributen wieder raussuchen und ggf. entfernen zu müssen, ist auch nicht schön.MfG ChrisB
--
RGB is totally confusing - I mean, at least #C0FFEE should be brown, right? -
"javascript:..." IST eine URL. Ich habe kein Skript in das href-Attribut geschrieben.
Also ist javascript: ein Protokoll? Wo kann ich das nachlesen, interessiert mich wirklich. Wenn du mir aber sagst, wo es steht, brauch ich nicht die RFCs zu durchforsten.
Diese konkrete Schreibweise <http://de.selfhtml.org/javascript/sprache/regeln.htm#namen@title=finde ich übrigens auch in der SelfHTML-Dokumentation> immer wieder
Ja, da steht es seit langer Zeit drin. Wie ich aber oben schon geschrieben hab, ist Selfhtml weder Standard noch in irgendeiner Weise bindend. Oder glaubst du, nur weil es da steht, ist es automatisch richtig?
»javascript:«-URLs werden in HTML5 standardisiert.
http://dev.w3.org/html5/spec/webappapis.html#javascript-protocol
Ok, ich wusste nicht, dass es vorher nicht standardisiert war.Tja, ich schon, deshalb überhaupt mein Einwand.
Das hätte ich dann auch gern mal gewusst. Manchmal hat man direkt das Gefühl, dass für viele Leute hier nur der Stil gut ist, den sie selbst verwenden bzw. sich angeeignet haben. Viele Wege führen nach Rom, und nicht alle sind schmutzige Trampelpfade.
Wenn dein einziger Anwendungsfall für Javascript das Schliessen von Popups ist, dürfte dich auch kein Standard interessieren.
Für mich ist das ein guter Stil: <button style="button" onclick="self.close()">schliessen</button>
Und dann formatiere ich diesen Button per CSS so wie ich will. Und jetzt bin ich gespannt, wie mir jemand erklärt, dass hier der Event-Handler schlechter Stil ist.
Allerdings muss man auch beachten, dass das ein einfacher Beispieltest für mich war, um das Problem nachzuvollziehen.
Gerade bei Beispielen sollte man auf Standardkonformität und sauberen Code achten. Denn wenn ein Anfänger schon fehlerhaften, unsauberen oder schlechten Code bekommt, lernt er evtl. auf dieser Basis weiter. Ich bin der Meinung, jeder soll erstmal sauber Programmieren lernen, dirty Hacks kommen später von allein.
-
Für mich ist das ein guter Stil: <button style="button" onclick="self.close()">schliessen</button>
Und dann formatiere ich diesen Button per CSS so wie ich will. Und jetzt bin ich gespannt, wie mir jemand erklärt, dass hier der Event-Handler schlechter Stil ist.
Mit deinen eigenen Argumenten:
self und close sind nicht standardisiert. Sie werden erst mit HTML5 standardisiert. Wobei HTML5 noch kein Standard ist. Also: Falsch. Und schlechter Stil. Also: Nicht verwenden.Mathias
-
Mit deinen eigenen Argumenten:
self und [link:http://dev.w3.org/html5/spec/browsers.Kann sein, hab ich nicht nachgesehen. Und wenn ich sowas aus dem Kopf schreib, passiert das.
Somit hast du recht, schlechter Stil. Da du den Inline.Event-Handler aber nicht bemängelt hast, gehe ich davon aus, dass dieser in diesem Fall ok ist und/oder du keine bessere Lösung hast.
-
-
-
-
Wenn sich das in den letzten Jahren nicht geändert hat, ist das immer noch nicht STandardkonform. Desweiteren gehört in href="" eune URL und kein Script.
»javascript:«-URLs werden in HTML5 standardisiert.
http://dev.w3.org/html5/spec/webappapis.html#javascript-protocolBestätigt meine Aussage. Somit ist er überall, wo nicht HTML5 verwendet wird, falsch.
Warum ist es mieser Stil? Wie sieht das Schließen eines per JavaScript geöffneten Popup-Fenster in gutem Stil aus?
Wenn etwas nicht im Standard ist, ist es automatisch mieser Stil. Oder findest du es gut, wenn jeder Browserhersteller sein eigenes Süppchen kocht und daruch für jeden Browser die Webseite angepasst/getestet werden muss?
Das Einbetten von JavaScript ins HTML, besonders über Inline-Event-Handler, ist allgemein schlechter Stil, ja.
Wo ist der Unterschied von einem Link zu einem Inline-Event-Handler? Wird der Seitenaufbau verzögert oder irgendein Sicherheitsloch geöffnet? Wenn letzteres schlechter Stil ist, würde mich der Unterschied interessieren.
Im Falle einer Funktionalität, die nur bei aktiviertem JavaScript existiert und sichtbar ist, kann man einen »javascript:«-Link aber ohne Probleme verwenden. Siehe auch diese Diskussion.
Eine Diskussion in diesem Forum ist für mich nicht wirklich entscheidend. Das kann mir maximal einen Denkanstoss geben, mehr nicht. Selfhtml ist weder eine Vorschrift noch ein Standard. Weder das Forum noch die Doku.
Beim Öffnen und Schließen von Popups ist das aber ein kleineres Problem – die Referenz auf das window-Objekt des Popups über den globalen Scope zugänglich zu speichern, hat mehr Vorteile.
Ich habe meine erste Aussage nicht aufgrund eines bestimmten Anwendungsfalles getätigt, ich habe lediglich angemerkt, dass javascript: kein Standard und somit falsch ist. Wenn sich das in HTML5 geändert hat, bestätigt das eben diese Aussage. Aber für mich ist HTML5 immer noch ne Randerscheinung, da die Browser es noch nicht komplett unterstützen. Ich hoffe aber, das ändert sich in den nächsten 1-2 Jahren, wenn auch due Nachzügler endlich passende Updates machen.
-
Hi,
Ich habe meine erste Aussage nicht aufgrund eines bestimmten Anwendungsfalles getätigt, ich habe lediglich angemerkt, dass javascript: kein Standard und somit falsch ist. Wenn sich das in HTML5 geändert hat, bestätigt das eben diese Aussage. Aber für mich ist HTML5 immer noch ne Randerscheinung, da die Browser es noch nicht komplett unterstützen.
Du argumentierst also, dass man JavaScript-URLs erst dann einsetzen könnte, wenn HTML5 verbreitet genug wäre – und ignorierst geflissentlich, dass HTML5 auch in diesem Punkt nur etwas standardisiert, was seit Jahr(zehnt)en in Browsern problemlos funktioniert.
MfG ChrisB
--
RGB is totally confusing - I mean, at least #C0FFEE should be brown, right?-
Du argumentierst also, dass man JavaScript-URLs erst dann einsetzen könnte,
Würdest du mir bitte sagen, wo ich das gesagt habe?
Ich finde es immer wieder schön, was alles in meine Aussagen reininterpretiert wird.-
Hi,
Du argumentierst also, dass man JavaScript-URLs erst dann einsetzen könnte,
Würdest du mir bitte sagen, wo ich das gesagt habe?
Du hast argumentiert, dass sie „falsch“ wären, weil kein Standard - und anerkannt, dass sich das mit HTML5 ändert.
Wenn man sie deiner Meinung nach damit trotzdem noch nicht einsetzen kann/darf – dann müsstest du dafür jetzt aber ein anderes Argument als „kein Standard“ finden.
MfG ChrisB
--
RGB is totally confusing - I mean, at least #C0FFEE should be brown, right?-
Du hast argumentiert, dass sie „falsch“ wären, weil kein Standard - und anerkannt, dass sich das mit HTML5 ändert.
Richtig, also kein Wort, dass man sie nicht einsetzen darf, nur dass die Seite dann nicht Standardkonform, also fehlerhaft(falsch ist.
Wenn man sie deiner Meinung nach damit trotzdem noch nicht einsetzen kann/darf – dann müsstest du dafür jetzt aber ein anderes Argument als „kein Standard“ finden.
Meine erste Aussage war, dass es pfui ist. Dann kam hinzu, dass es kein Standard war(!). Alles andere versuchst du mir in den Mund (auf die Tastatur?) zu legen. Da das weder zielführend noch sinnvoll ist, belassen wir es dabei. Oder siehst du einen Sinn in einer solchen "Diskussion"?
-
-
-
-
Hallo,
Wenn etwas nicht im Standard ist, ist es automatisch mieser Stil.
Bitte informiere dich doch über die Entwicklung der heutigen Frontend-Webtechniken in den letzten 15 Jahren, bevor du solche kühnen Aussagen tätigst. Auch lange nach der Webstandards-Bewegung sind große Teile der verwendeten HTML-, CSS- und JavaScript-Techniken nicht final standardisiert. Dennoch sind viele Techniken gut unterstützt und werden praktisch breit angewandt.
»javascript:« ist ab Netscape JavaScript 1.0 spezifiziert und war seitdem, wie auch der große Rest der JavaScript-Hostumgebung, bloß Quasi-Standard. Sämtliche JavaScript-Implementationen waren mit dieser Spezifikation kompatibel, weitere Spezifikationen wie JScript bezogen sich darauf. Es gab sogar mal einen Anlauf, um das URI-Schema als RFC zu verabschieden.
Mit HTML5 hat sich die Situation nur insofern geändert, dass weitere seit 1996 existierenden Techniken von der WHATWG spezifiziert werden und in eine kommende W3C-Spezifikation einfließen. Die Standardisierungsprozesse haben sich zudem geändert, sodass es heutzutage normal ist, dass man Techniken verwendet, die entweder Quasi-Standards sind oder sich noch im Prozess der Spezifizierung befinden. Bis eine W3C-Spezifikation eine »Recommendation« wird, dauert es sehr lange.
Ferner ist HTML5 keine zukünftige in sich geschlossene Version, sondern eine abwärtskompatible Spezifikation zum Umgang mit sämtlichen existierenden HTML-Dokumenten. Der Definition nach gibt es daher kein »wo HTML5 nicht verwendet wird«. HTML5-fähige Browser verarbeiten alle Dokumente gemäß HTML5-Regeln, müssen »javascript:« also auch bei HTML-2-Dokumenten unterstützen.
Zu JavaScript-Standards, zur Bedeutung von HTML5 und zur aktuellen Lage der Webstandards siehe:
http://aktuell.de.selfhtml.org/weblog/javascript-standards
http://molily.de/js/standards.html
http://molily.de/weblog/html-geschichte
http://www.webkrauts.de/2011/08/29/was-sind-webstandards/
http://molily.de/weblog/webstandardsMathias
-
Dennoch sind viele Techniken gut unterstützt und werden praktisch breit angewandt.
Wie z.B. Frames. Willst du jetzt behaupten, deshalb sind sie guter Stil (das ist nur ein Beispielvon vielen)
Du hast mit deinen Aussagen sicher Recht, aber pauschal zu sagen, alles was verbreitet ist, ist gut, halte ich für wesentlich gewagter als meine Aussage.
Und nur um meinen Standpunkt klarzustellen: Gut für ein Projekt ist das, was mit möglichst geringen Aufwand möglichst grossen Nutzen bringt. Das kann schlechter Stil sein aber trotzdem Sinn machen. Dazu gehören z.B. Inline-Event-Handler. Denn um einen solchen zu inte3grieren, ein Script zu schreiben, der diesen in den DOM einhängt, halte ich für überzogen.
Was hier wieder für eine Diskussion losgetreten wurde aufgrund einer einfachen Frage von mir, ist aber wieder faszinierend. Zusätzlich hab ich aber einiges gelernt, was ich grundsätzlich als Positiv empfinde :)
Mein Standpunkt ist immer noch der Gleiche, mein "schlechter Stil" wird sicher bleiben (s.o.) und was die Zukunft bringt, wird sich zeigen.
-
Du hast mit deinen Aussagen sicher Recht, aber pauschal zu sagen, alles was verbreitet ist, ist gut, halte ich für wesentlich gewagter als meine Aussage.
Ich habe diese Aussage zu keinem Zeitpunkt getätigt; bitte drehe mir das Wort nicht im Munde um. Ganz im Gegenteil, hättest du meinen jüngsten Artikel gelesen, den ich verlinkt habe.
Mein Standpunkt ist immer noch der Gleiche
Multi schafft es, keine Ahnung von der Materie zu haben und gleichzeitig stets Recht zu behalten. Respekt.
Mathias
-
-
-
-
-
-
-
-
-
Hallo Leute
mmm hab mich nicht klar ausgedrückt. Ich kann die Fenster schon zumachen. Aber nur solange ich das opener fenster nicht neu einlese. ich meinte mit speichern, im sinne von ablegen in einer "input type hidden variable", so das ich auch später noch auf die werte zugreifen kann. oder vielleicht auf disk speichern mit nem cookie oder so :-)
Grüsse Horst
und ein schönes Wochenende an alle
-
Hi,
mmm hab mich nicht klar ausgedrückt. Ich kann die Fenster schon zumachen. Aber nur solange ich das opener fenster nicht neu einlese.
Logisch, dabei gehen die Variablen, die zu dessen Kontext gehören, natürlich verloren.
ich meinte mit speichern, im sinne von ablegen in einer "input type hidden variable", so das ich auch später noch auf die werte zugreifen kann. oder vielleicht auf disk speichern mit nem cookie oder so :-)
In allen diesen Kontexten kannst du nur textbasiert Werte speichern.
Eine Referenz auf ein Objekt – wie das Ergebnis von window.open eine darstellt - kannst du aber nicht in einen Text überführen, so dass sie anschließend aus diesem auch wieder in die Referenz überführbar wäre.
Aber nur solange ich das opener fenster nicht neu einlese.
Die einzige mir bekannte „Lösung“ wäre es, darauf zu verzichten - also das öffnende Dokument nicht zu wechseln.
Ins Hauptfenster zunächst ein Frameset mit einem Frame (alternativ: Iframe) hinein zu laden, den Wechsel der eigentlichen „Seite“ nur noch innerhalb des Frames vollziehen - und die Popups aus der übergeordneten window-Instanz heraus öffnen und die Referenzen darauf auch dort ablegen.MfG ChrisB
--
RGB is totally confusing - I mean, at least #C0FFEE should be brown, right?-
Hallo ChrisB
Ins Hauptfenster zunächst ein Frameset mit einem Frame (alternativ: Iframe) hinein zu laden, den Wechsel der eigentlichen „Seite“ nur noch innerhalb des Frames vollziehen - und die Popups aus der übergeordneten window-Instanz heraus öffnen und die Referenzen darauf auch dort ablegen.
Dies ist mir auch durch den Kopf gegangen. Werde mich also doch noch mit frames beschäftigen müssen. Zuerst lass ich den "Bug" mal drin.
Ich würde gerne im MainFenster bleiben, aber soviel ich weiss gibts kein Frame over Frame und mit JAVA und dann Tabs in Tabs will ich nicht anfangen.
Gruss Horst
Danke an alle.
-
-
Wenn das Popup wirklich nötig ist (ist es das wirklich?), würde ich auf der Hauptseite die neuen Daten nur per Ajax holen und in die aktuelle Seite schreiben.
Damit musst du nie die Seite wechseln und das Objekt bleibt erhalten. Da das Popup nur mit Javascript funktioniert, sollte Ajax kein Problem sein.
-