nicht angemeldet
Hi Calocybe,
versteh ich dich dann richtig, wenn ich dich so verstehe, daß du
Webseiten als ungeeignet als Grundlage für jedweilige Applikation
siehst (und man andere Wege suchen sollte)?
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.
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).
Ich würde also durchaus HTML als Realisierungssprache für bestimmte Aspekte einer HTTP-basierten Anwendung (beispielsweise Formulare und Links) als sinnvoll ansehen.
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.
Gleichzeitig würde ich allerdings auch nicht versuchen, meine Anwendung dann "mit Gewalt" strict-valide zu bekommen (und erst recht nicht mit JavaScript dafür tricksen und eine zusätzliche Abhängigkeit einbauen! Vielleicht kann ja doch einer von den DAUs JavaScript abschalten, und dann bin - bis zum Beweis des Gegenteils - erst mal ich schuld, weil seine Anwendung nicht läuft ...). Denn wer
a) von einer solchen Anwendung verlangt (vertraglich, per Auftrag),
daß "strict HTML" verwendet werden muß, gleichzeitig aber
b) Features fordert, die sich nicht mit "strict" realisieren lassen,
der bekommt von mir die Aufgabenstellung zurück mit "entweder a) oder b) - beides zusammen ist technisch unmöglich, bitte entscheiden Sie sich".
Viele Grüße
Michael