Alertfenster

[molily]

Hallo, Martin und Alexander,

Man könnte natürlich auch gleich eine "richtige" Web-Applikation bauen, die mit allen gängigen Browsern incl. IE funktioniert, das erspart einem das Theater, wenn man (endlich) merkt, daß der IE oder Windows eben nicht allen Anforderungen genügt.

ACK.

dazu muss man sagen, dass es auch in der Entwicklung mehr kostet, was sich dann aufs Produkt auswirkt. Ausserdem geht Manches nicht mehr. Ich hab z.B. letzte Woche eine MessageBox gebraucht, um eine Ja/Nein/Abbrechen-Abfrage zu machen. Da bot sich showModalDialog einfach an.

Genau das denke ich auch, auch deinen Schluss daraus:

Aber generell dachte ich, dass sich ein "normaler" Client, sprich ein eigenständiges Programm, noch mehr gelohnt hätten. Da würde vieles einfacher gehen, z.B. das Mitschleppen von Session-Variablen von Seite zu Seite würde einfach entfallen.

Ähm, ich habe ja keine Ahnung, aber wieso verwendet man dann HTTP-Anwendungen, wenn man doch einen um ein vielfaches effizienter bedienbareren Client entwickeln könnte, welcher nahtlos an die Serveranwendung angepasst ist? Je spezieller die Aufgaben sein sollen, desto naheliegender wäre ein eigenständiges Clientprogramm, ob das HTTP weiterhin als Protokoll verwendet wird, muss nicht ausgeschlossen werden, schließlich bietet sich es zur Übermittlung von Daten in XML-Sprachen an. Hypertext ist nunmal per se nicht das richtige Medium und ein Browser nicht das perfekte Benutzerinterface für eine Anwendung, ich kann vollkommen verstehen, wieso der Browser durch die Scripterweiterung des MSIEs gefügig gemacht werden muss, schließlich werden diese Anforderungen an einen Hypertextagent normalerweise nicht gestellt und der Browser wird zweckentfremdet. Interaktion mit dem Benutzer durch von dir genannte Standarddialoge ist in der Regel einem auf dem Clientrechner ausführbaren speziellen Programm vorbehalten, ein Browser eignet sich für solche Aufgaben eher wenig.

Andersherum würde ich für den Fall, dass auf den Browser als Clientprogramm nicht verzichtet werden soll, dafür plädieren, dass eine Intranet-HTTP/HTML-Anwendung soviel wie möglich serverseitig überprüfen sollte, einerseits weil der Browser durch Fehlbedienung beziehungsweise einer Bedienung, welche dem gewöhnlichen Hypertextnavigieren eigen ist, unzuverlässig ist, es sei denn, man staucht den Browser so zusammen, dass er nur das Klicken auf Links sowie das Ausfüllen von Formularen erlaubt, das dann natürlich durch die clientseitigen Möglichkeiten überprüft werden könnten etc.
Generell ist es kein Anzeichen von hoher »Systemstrukturqualität«, die Flexibilität einer HTTP-Anwendung dadurch zu begrenzen, sie auf ein spezielles Clientprogramm zu münzen, wenn es unnötig ist und ebenso die Ünterstützung verschiedener Clientplatformen und generell Interfaces möglich wäre. Wenn das Intranet beispielsweise aus Rechnern verschiedener Betriebssysteme besteht, ist eine auf MSIE geprägte Anwenderoberfläche (hier zeigt sich erneut die Paradoxie) unzuverlässig, genauso müsste die Serveranwendung komplett umgeschrieben werden, wenn sich das Unternehmen entscheidet, einen anderen Browser als MSIE einzusetzen, weil die Supportverträge auslaufen oder man sich entscheidet, einen auf Gecko basierenden Client zu entwickeln (was IMHO die perfekte Lösung ist, da man nicht auf Hypertext verzichten muss, den Client aber optimal einschränken und erweitern kann, ohne einen komplett eigenen Client zu schreiben).

Grüße,
Mathias