nicht angemeldet
Hi Calocybe,
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?
Ich meine, daß es überhaupt nicht so sehr HTML _ist_, was sich für die _Anwendung_ eignet, sondern nur für einen Teilaspekt derselben.
Wenn andere Teilaspekte in einer Browser-Umgebung nicht hinreichend gut unterstützt werden (Du selbst hast ja die Session-Problematik genannt), dann hilft mir das schöne HTML auch nichts.
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.
So etwas habe ich als Entwickler desselben gerade hier vor mir auf dem Bildschirm (Framesets, sage ich nur ... ;-)
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.)
Zum Glück muß ich mir diese Frage nicht stellen.
JavaScript ist ohnehin Voraussetzung, und das reicht mir in diesem Kontext.
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.
Ich rede von einer Eskalations-Strategie. Wieviel kann ich meinem Besucher zumuten? Ist das Feature X wirklich so toll, daß ich allein dafür eine zusätzliche Technologie, Sprache etc. einzusetzen bereit bin - und ist es auch mein Besucher?
Die Sache mit dem Firewall zaehlt nicht. Wer solche
Anwendungen betreiben will, muss seinen Firewall
entsprechend weit aufmachen, da hilft nun alles
nichts.
_Meine_ Firewall _ist_ "auf", in dieser Hinsicht.
Aber die meines Besuchers?
(Ich sollte mal wieder erwähnen, daß meine Besucher ausschließlich Firmen sind, und zwar paranoide Besucher - solche, die _Dein_ Geld in ihren Rechnern verwalten müssen, und das soll bitte schön sicher sein.)
[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!
Das geht natürlich nicht. Wenn Du clientseitige Intelligenz in diesem Maße forderst, dann muß eine Programmiersprache her.
Um genau solche Dinge zu tun, driften wir inzwischen mehr und mehr in die Richtung, unsere HTTP-Requests selbst via JavaScript abzusetzen, anstatt alles über Links und Formulare zu erledigen ...
Aber HTML/HTTP als *Grundlage/Basisgeruest* einer
App, das sehe ich nicht.
Ich habe mir den Quelltext der ComDirekt-Schnittstelle nicht durchgelesen, aber Java nutzt sie nicht, und JavaScript auch nicht für essentielle Dinge, glaube ich.
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.
Ich fürchte, auch die rein kommerzielle Sicht (lieber einen Kunden mehr als die "reine Lehre" bei der Lösung) wird nicht innerhalb der nächsten Jahre aussterben ...
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).
Ich weiß. Das ist ein Teil unserer "Lebensader", das erkannt zu haben (und etwas dagegen zu tun ;-).
Bitte haltet den Thread bis Montag oder Dienstag
warm, ich muss mal ein paar Tage ins Off. ;-)
Schaun 'mer mal ...
Viele Grüße
Michael