nicht angemeldet
Moin moin!
Yupp, der Meinung bin ich in der Tat. Oder um genau zu sein: Nicht
unbedingt als "ungeeignet", aber auf jeden Fall "nicht dafuer
gedacht". Die *Eignung* sehe ich in der Folge aber auch nicht gegeben.
ich denke, das ist so aber auch nicht die Frage.
Ich würde zumindest nicht eine Anwendung mit HTML bauen wollen, _weil_ ich HTML dafür als geeignet einstufe. Es ist m. E. vielmehr HTTP, was sich für die Anwendung mehr oder weniger gut eignet.
Das verstehe ich jetzt nicht. Meinst Du, *nur* weil Du HTML als dafuer geeignet einstufst, willst Du noch lange nicht eine Anwendung darauf aufbauen?
Eines sollte ich vielleicht mal noch zur Klarstellung sagen. Wenn ich HTML sage, meine ich richtiges HTML, also Strict. Transitional sehe ich mehr als Verunreinigung, dessen Betrachtung wegfaellt, solange man von HTML redet. (Man kann aber von mir aus eine Erweiterung definieren, die transitional-aehnlich ist, das dann aber bitte anders nennen. In diese Richtung geht ja modularisiertes XHTML.)
Und natuerlich sehe ich HTML auch immer in Verbindung mit HTTP, also in seiner natuerlichen Umgebung. HTTP bringt aber aufgrund seiner Nicht-Verbindungsorientiertheit einige Probleme mit sich, wenn man damit beliebige Apps bauen will. (Schon die klassische Frage, wie lange haelt sich irgendwer irgendwo auf, laesst sich nicht beantworten.) (Das keep-alive von HTTP/1.1 aendert an der Situation uebrigens nichts, da dadurch zwar die TCP-Verbindung bestehen bleibt, aber die HTTP-Verbindungen trotzdem viele einzelne sind, und nur letzteres interessiert eine hinter dem Webserver agierende Serveranwendung.)
Und dann sei noch gesagt, dass ich bei Apps nicht von klassischen Anwendungen, die fuer's Web in seiner jetztigen Form praedestiniert/konzipiert sind, rede, sondern von *beliebigen* Anwendungen, denn dahin soll uns ja die Zukunft AFAIK fuehren. Man denke nur mal an eine Anwendung, die Auswahllisten aehnlich der Selfhtml Quickbar zur Verfuegung stellt, die zweite Selectbox aber immer in Abhaengigkeit vom ausgewaehlten Punkt der ersten mit anderen Daten gefuellt ist. Die verschiedenen moeglichen Daten sollen aber nicht alle im Javascript-Quelltext stehen, sondern bei Auswahl dynamisch ueber's Internet geladen werden. Das ist mit ein paar Klimmzuegen und schmutzigen Tricks vielleicht noch mit JS realisierbar, aber kann man dann HTML in Verbindung mit JS noch als *geeignet* dafuer bezeichnen? (HTML alleine sowieso nicht.)
Und die Frage ist dann halt, ob die via HTTP übermittelten Daten dann sinnvollerweise etwas Einfaches, verbreitetes, Nicht-Proprietäres wie HTML sein sollen (was beispielsweise von sämtlichen Firewall-Konfigurationen der typischen Firmenkunden toleriert wird, weil es keine client-seitige Intelligenz repräsentiert und damit keine Sicherheitskonzepte unterläuft), oder ob man etwas Komplexeres, Flexibleres, Intelligenteres ebenfalls einsetzen darf (das fängt bei JavaScript und Cookies an und umfaßt sicherlich auch Java, Flash und ActiveX, falls die entsprechende Aufgabenstellung dies erlaubt).
Du redest hier von reinem HTML, sogar ohne JavaScript. IMHO laessen sich selbst Anwendungen geringer Komplexitaet nicht ohne clientseitige Intelligenz (at least JS), also nur POST-basiert, sinnvoll realisieren (wobei "sinnvoll" auch "benutzerfreundlich" beinhaltet [1]). Sieht man sich z.B. Homebanking-Programme an, so sind diese fast alle in Java geschrieben. Einige kommen auch nur mit HTML und JS-Zwang aus, aber wirklich nur HTML?
Die Sache mit dem Firewall zaehlt nicht. Wer solche Anwendungen betreiben will, muss seinen Firewall entsprechend weit aufmachen, da hilft nun alles nichts.
[1] Bezogen auf obiges Beispiel heisst das, ich will nicht bei jeder Auswahl eines Eintrags in der ersten Selectbox das Formular abschicken, auf dass die zweite gefuellt werde, denn schliesslich ist das nur ein kleiner Teil einer groesseren "Seite" (oder wie immer man das dann nennt). Es muss moeglich sein, dass der Client eine Verbindung zum Server aufbaut (oder besser eine bestehende nutzt), nur die benoetigten Daten in huebsch verpackter Form (d.h. leicht zu parsen) abfragt und diese in die zweite Liste eintraegt -- alles andere bleibt unveraendert, incl. der aktuellen Scrollposition innerhalb der Seite. Und es muss z.B. auch moeglich sein, dass der Benutzer sich noch waehrend der Anfrage doch fuer einen anderen Eintrag entscheidet, woraufhin die aktuelle Anfrage abgebrochen wird und eine neue gestartet. Und jetzt realisiere mir das bitte einer mit HTML, von mir aus auch Transitional. Da bin ich aber gespannt!
Ich würde also durchaus HTML als Realisierungssprache für bestimmte Aspekte einer HTTP-basierten Anwendung (beispielsweise Formulare und Links) als sinnvoll ansehen.
Fuer *bestimmte Aspekte*, dem habe ich nicht widersprochen. Ich sehe z.B. schon Potential darin, Teile des Screendesigns mit HTML+CSS zu bewerkstelligen, da die Auto-Layout-Faehigkeiten dieser Kombination beachtlich sind. Z.B. kann man mit dem allseits beliebten 'em' (;-)) das Layout teilweise abhaengig von der vom Benutzer praeferierten Schriftgroesse machen, sodass weit besser auf die Wunsche des Benutzers eingegangen werden kann als in heute existierenden Applikationen, in denen das alles fest verdrahtet ist (insbesondere gilt das fuer Windowsworld).
Aber HTML/HTTP als *Grundlage/Basisgeruest* einer App, das sehe ich nicht.
Die Möglichkeit, auf diese Weise plattformübergreifende GUIs ohne die Installation von proprietärer Software auf Kunden-Rechnern zu realisieren, ist einfach zu verlockend, um sie bei passender Gelegenheit nicht einzusetzen.
Wenn Du darauf anspielst, dass Webbrowser im Jahr 2002 quasi ueberall vorhanden sind und man diesen wirtschaftlichen Vorteil ausnutzen sollte, hast Du vielleicht recht. Aber ich bin Perfektionist und mein Interesse ist, eine Aufgabe vom Standpunkt der Softwarearchitektur gut/vernuenftig zu loesen. Wirtschaftliche Betrachtungen lasse ich da aussen vor, da diese meistens zu Kompromissloesungen fuehren, die vom genannten Standpunkt aus unvernuenftig sind. Aus dieser Ecke kommt also meine Argumentation, und diese hat IMHO vor allem auf *lange* Sicht ihre Berechtigung.
Ausserdem wollen wir aber nicht vergessen, dass im Jahr 2002 viele Anbieter sehr wohl auf die Faehigkeiten einer proprietaeren Spezialsoftware setzen, die es nur fuer einige ausgewaehlte Plattformen ueberhaupt gibt (IE/Windows,Mac).
Gleichzeitig würde ich allerdings auch nicht versuchen, meine Anwendung dann "mit Gewalt" strict-valide zu bekommen [...]
Ja, das sowieso nicht. Das faende ich komplett unlogisch, aus dem im vorhergehenden Posting genannten Grund.
Eines will ich noch loswerden: Ich habe nur ueber HTML bis Version 4 (einschliesslich XHTML 1.0) geredet. Auf XHTML ab 1.1 lassen sich meine Ueberlegungen vielleicht nicht mehr anwenden. Die "Modularization of XHTML" schafft jedenfalls wieder viel Platz fuer Phantasie, was man damit alles machen kann. Siehe dazu http://www.w3.org/MarkUp/.
Bitte haltet den Thread bis Montag oder Dienstag warm, ich muss mal ein paar Tage ins Off. ;-)
So long
--
Einfache Maschinen brauchen einfache Bedienoberflaechen -- Command line interpreter fuer Fahrkartenautomaten!