10.05.2006
Dialogboxen mit Webseiten als Inhalt
Der Internet Explorer hat ein paar interessante Feature, wie z.B. die showModalDialog Methode, sucht man eine Entsprechung im DOM (Crossbrowserstandarddingens) sieht es schon düsterer aus. "window.open" hält eben nicht den Prozess an und verhindert, dass die Verbindung von einem Fenster zum anderen Unterbrochen wird und der schöne Dialog zwischen zwei Fenstern auch dann noch funktioniert, wenn zwischenrein der Nutzer am Telefon hängt, eine neue Instanz öffnet, und zig andere Seiten ansurft und dann irgendwann stundenspäter zurück zu seiner unterbrochenen Arbeit zurückkehrt. Etwas ähnliches scheint window.opener zu sein, doch scheint es mir nicht Ratsam überhaupt ein neues Fenster aufzumachen und statt dessen besser nur einen CSS-Layer zu erzeugen. Siehe hierzu auch den Beitrag zu Window popping im DOM-Scripting-Blog, das aber ist wenn es so elegant wie im IE funktionieren soll nur mit HTTPrequest möglich, so dass in die Seite je nach Status der Arbeit Teile nachgeladen und anschließend auch wieder aus der Seite rausgeworfen werden können. Denn es macht keinen Sinn das Equivalent des Romans Krieg und Frieden in eine einzige Seite zu laden.
DOM-Experten mögen mir das Licht zeigen. Ich habe es beim Stöbern im Netz noch nicht gefunden, mit dem ich so etwas feines wie den showModalDialog crossbrowser hinbekäme. Es macht es verständlich, dass der eine oder andere auf Crossbrowser verzichtet und bei Webapplikationen in der Asministration den Microsoft Internet Explorer schlicht voraussetzt.
Nachtrag: Hier noch eine Hilf-Dir-Selbst-Lösung für Firefoxler: showModalDialog in Firefox and frames, was natürlich keine wirkliche Lösung darstellt, sondern maximal eine Krücke für diejenigen, die mit ihrem Browser auf öffentlichen Seiten sind, die IE-only gescriptet wurden, was ich nun widerrum nicht gut heiße. Denn eine Seite die im Netz für alle gemacht wird, sollte niemandem vorschreiben, welchen Browser er nun verwenden sollte. Eine Applikation aber die intern genutzt wird, kann sich auf einen Browser beschränken. Schließlich ist es die Entscheidung des Nutzers, ob er diese oder die entsprechende Applikation des Konkurrenzbrowsers nutzen will.
Für die kontextsensitive Hilfe ist dann doch showModelessDialog() die bessere Wahl. Das Fenster kann im Hintergrund stehenbleiben, während man den Prozess fortfährt und wird geschlossen, wenn alles fertig ist und das ursprüngliche Dialogfenster, das für die Bearbeitung der Seite oder was immer zustänig ist, geschlossen wird.
Filed under: Programmierung, Webtechniken
8 Comments
May 10th, 2006 at 17:33
Ich glaube nicht, dass du etwas für alle Browser in diese Richtung finden wirst. Das der Internet Explorer dieses “Feature” enthält hängt wohl mit dem von Microsoft verwendeten JScript (Konkurrenz zu Netscapes JavaScript) zusammen, die man mit VBScript zusammen unter anderem auch für HTApplications verwenden kann.
Das Internet (und deren Browser) sind halt nicht für Webapplications gebaut, sondern für schnöde HTML-Seiten.
Wer unbedingt einen modalen PopUp haben will, der muss sich mit JavaScript behelfen und alle paar Sekunden dem PopUp den Focus geben, dass müsste gehen (lässt sich im Firefox z. B. aber auch deaktivieren). Was das PopUp an sich angeht wäre die Eigenschaft ‘dependent’ vielleicht ganz interessant – je nachdem was man haben will. Um das wirklich browserweit zu lösen, wird man wohl auf Layer zurück greifen müssen, was ja kein Schaden sein muss – hat man doch dann wenigstens mehr Kontrolle über das “Fenster”
Übrigens, wer suchet der findet auch (sicher) eine Firefox “only” Methode mittels XUL und Co. – nicht das noch einer glaubt nur der Internet Explorer kann sein eigenes Süppchen kochen.
May 10th, 2006 at 18:07
Alle muss gar nicht sein. Die meisten modernen Browser würde mir schon genügen. So die üblichen Verdächtigen, wie MSIE, FF, Opera und Safari bis ein, zwei Generationen zurück würden mir für den Anfang schon genügen.
Javascript Aktualisierung ist nicht notwendig, mit opener kann man einen Rückgabewert an das ursprungsfenster geben und wenn man dann noch Serverseitig die Prozeduren erst dann fortsetzt, wenn die Antwort vom Popup kommt, hätte man auch diesen Effekt von showModalDialog … wobei leider noch die enge verknüpfung fehlt, dass das Fenster sich nicht schließen lässt. Das könnte man mit einem onBlur reload solange der Rückgabe wert nicht da ist, zwar auch simulieren aber nur mit sehr nervigen Effekten.
Auf Layer und CSS war ich auch schon gekommen. Dies gepaart mit iFrames oder mit HTTPrequest verhindert, dass man in eine Datei die gesamte Applikation mit gleich beim erste Start laden muss, sondern nach und nach die Programmteile und auch nur wenn Bedarf ist.
Apropos XUL ist nicht ähnliches auch mit PHP, Zope, Perl in Kombination mit XML wieder Browserunabhängig möglich? … Zumindest bei PHP habe ich letztens etwas in diese Richtung gelesen, allerdings ohne mich näher damit zu befassen.
May 10th, 2006 at 21:37
> ist nicht ähnliches auch mit PHP, Zope, Perl in Kombination mit XML wieder Browserunabhängig möglich?
Ehrlich gesagt hab ich keine Ahnung was du meinen könntest. XUL als Auszeichnungssprache für Benutzeroberflächen brauch nun mal eine Software die es interpretiert, wie z. B. die Gecko-Engine, da kann PHP und Perl als serverseitige Sprachen und Zope als Server wenig machen, wenn die Software das XUL nicht verstehen, oder hab ich jetzt etwas übersehen?
> zwar auch simulieren aber nur mit sehr nervigen Effekten.
Eben. Deshalb sollte man das lieber gleich lassen. Entweder man schreibt sich in JavaScript sein eigenes “Fenster”, also ein Layer, oder aber man darf nicht JavaScript verwenden. Wobei meines Wissens Flash und Java Applets dies auch nicht können, also zurück zu den “normalen” Anwendungen. Eine Exe wäre doch auch mal wieder was schönes, muss ja nicht immer alles von der Echse unterstützt im Firefox laufen
Die Frage ist auch meist, ob überhaupt ein neues Fenster nötig ist, dass modal ist. Mir fällt nämlich momentan kein Beispiel ein, wo so etwas sinnvoll ist – im Gegenteil, mir fallen ein paar Anwendungen ein wo ich mir denke: Warum um Gottes Willen hat das Fenster die Eigenschaft Modal? (Oft in einem Atemzug mit: Warum lässt sich die Größe nicht ändern? Nicht Mini- oder Maximieren? Verschieben? …) Da denkt ich mir manchmal auch meinen Teil und überlege noch mal wer hier jetzt wen steuert: Ich die Anwendung oder die Anwendung mich? z. B. beim Firefox der Einstellungsdialog: Wieso kann ich nicht das normale Fenster aufrufen um z. B. eine URL zu kopieren? Richtig, weil mich die Programmierer ärgern wollen – wenn man nicht alles selber macht…
May 10th, 2006 at 22:00
Die Ausgestaltung des Modalen Fensters steht aber auf einem anderen Blatt. Ich finde es praktisch, dass ich Schritt A vor Schritt B steuern kann oder auch abhängige Fenster so mit einander verknüpfen kann, dass diese nicht ewig offen bleiben.
Modular ist wie hier schon erwähnt schon allein deswegen sinnvoll, weil es nicht viel Sinn macht, alle Funktionen zu laden, wenn nur wenige gebraucht werden. Und seit dem Modewort AJAX werden client- und serversetige Programme munter gemischt und kombiniert, daher bei mir diese unbedarfte Kombination.
XML und PHP lass ich etwas davon, dass und wie PHP diese Deklarationen interprätiert und auch XLS-Anweisungen wohl berücksichtigen. als echte Novizin in diesen Themen, gestehe ich, verstehe ich nicht alles und schwirrt auch viel munter durcheinander.
XML ist eine recht gute Alternative um Webapplikationen zu erzeugen. Ich meine ich hätte da auch etwas von Fenstersteuerung an irgendeiner Stelle mal gelesen … wobei ich nun nicht weiß, ob Layer oder echte Fenster gemeint waren.
Und es mag auch XLS mit im Spiel gewesen sein. Is auch egal. so ungefähr weiß ich wo ich suchen muss, sollte ich nicht wie jetzt den Luxus von IE-Only haben, weil das MiniCMS nur für den IE geschrieben wurde und es sich um ein Plugin für die Admin-Ebene handelt.
May 11th, 2006 at 17:11
Ich glaub, dass was du meinst ist [url=http://de.wikipedia.org/wiki/XSLT]XSLT[/url] – dafür kenn ich mich aber zu wenig damit aus, scheint aber wohl wirklich eine mächtige Sprache zu sein.
Was das nachladen betrifft: Ich kenn mich zwar mit AJAX nicht so aus, da sich meine Anwendungen in Grenzen halten, aber ich sehe auch nicht direkt dass Problem mit dem Nachladen. Daten kann ich ohne Probleme nachladen, JavaScript zwar nicht direkt, aber der JavaScript-Teil sollte sich ja eh in Grenzen halten, da dass nur wieder den Speicher belastet und auch nur kleinere Dienste tut. (Daten laden und einfügen, Werte prüfen,..) Im Zweifel kann ich auch nachladen per IFrame, eventuell auch mit eval() – aber die Funktion nutz ich nie und kenn daher auch nicht deren Möglichkeiten in JavaScript. Ganz nebenbei: Auf Gedeih und Verderb muss ja nicht nachgeladen werden. Wenn sich der Seitenaufbau grundlegend ändert, dann kann man auch mal wieder “normal” eine Seite aufbauen… auch wenn es schwer fällt
Wir haben es schließlich auch Jahre lang ohne diese tollen Buzzwords ausgehalten und alles besser gemacht haben sie ja auch nicht…
May 11th, 2006 at 17:26
Es geht nicht um Seiten, sondern um Applikationen, das ist schon ein Unterschied. Je nach Anwendung kommen da schon einen Menge Zeilen zusammen und dann jedes Mal Variablen, Zustände und Zeug mit nehmen in das nächste Formular oder Zwischenstände wegschreiben, zusammenschreiben, neu auswerten … da ist das Nachladen schon das eine oder andere Mal deutlich geschickter.
eval() sagt mir im Moment gar nichts.
May 11th, 2006 at 18:29
Ja klar, an vielen Stellen macht AJAX natürlich Sinn, keine Frage, gibt nur ebenso viele Stellen wo es blanker Unsinn ist. Ist aber auch Wurst für das Thema hier, ist mehr meine persönliche Einstellung zu AJAX…
Ich meinte jenes [url=http://de.selfhtml.org/javascript/objekte/unabhaengig.htm#eval]eval()[/url] was bei serverseitigen Sprachen auch vorhanden ist, dort allerdings (teilweise zurecht) verpönt ist, da ein Sicherheitsrisiko damit einhergeht und sich so unter dem Spruch “eval is evil” einen zweifelhaften Namen gemacht hat. Beim Client ist das ja aber egal, da man dort eh “schlechten” Programmcode einfügen kann, auch ohne eval.
Was ich noch meinte ist, dass meines erachtens JavaScript nicht sooo groß werden sollte. Wenn es zum Beispiel um das überprüfen von Formularen auf korrektes Ausfüllen geht, dann kann ich das tun in dem ich für jedes Formular eine eigene Funktion schreibe oder aber eine Funktion schreibe die sich erstmal die Regeln die für dieses Formular gelten läd und anhand dieser Daten dann die Überprüfung vornimmt. Letzteres wäre deutlich eleganter und ganz nebenbei viel kürzer, da ganz augenscheinlich nur eine Funktion anstatt für jedes Formular eine neue.
Mit Seiten meinte ich eigentlich Fenster: Also wenn die Applikation ihr Fenster stark verändert, man nicht alles zwingend dynamisch nachladen sollte, sondern lieber “normal” die Seite läd, wie es z. B. [url=http://www.writely.com/]Writely[/url] tut, wenn es von der Liste der Dokumente zum bearbeiten eines Dokumentes wechselt. Ein normales Programm läd ja auch nicht beim starten jedes kleine Feature und die letzte DLL, sondern erst wenn es wirklich benötigt wird. OpenOffice z. B. würde mich stark irritieren, wenn ich vom Textdokument ins Tabellendokument wechsle und ich feststelle, dass es die Tabellenoberfläche in die Textoberfläche hineinläd. Ich würde da ein zerstören der Textoberfläche und ein komplettes neuladen der Tabellenoberfläche als sehr viel sinnvoller erachten.
Wird wenigstens halbwegs klar, was ich damit sagen will?
May 11th, 2006 at 18:34
:/ Das kommt von den vielen Auszeichnungsprachen und der fehlenden Vorschaufunktion: Man benutzt mal wieder die falsche Sprache… vorallem wenn man mal wieder zwischen unterschiedlichen Systemen hin und her springt…
die Links wären übrigens in HTML statt BBCode eval() und Writely…