nicht angemeldet
Download erzwingen?
Hallo an alle!
das Problem ist allseits bekannt. bei Klick auf einen HREf eines *.doc, *.pdf etc. -Dokuments, öffnet sich bei entsprechendem Plug-In die dazugehörige Anwendung. Ich will Dateien aber explizit zum Download anbieten - und ohne dem Hinweis "Rechter Mausklick...".
Es gibt die Möglichkeit, einen anderen Dateityp anzugeben.
... href="dummy.pdf" type="application/octet-stream"...
Funktioniert aber nicht bei IE, der liest tatsächlich die Dateiendung aus.
Fragen:
1. Kann man mit JavaScript das Öffnen des "Speichern unter..."-Dialogs erzwingen (so wie print() das Drucken-Dialogfenster aufruft)?
2. Wenn nein, gibt es andere Möglichkeit (ich arbeite mit JSP)?
-
Hi,
das Problem ist allseits bekannt.
die Lösung auch. Sie steht hinreichend oft im Archiv.
Ich will Dateien aber explizit zum Download anbieten
Du hast übrigens gerade einen Download meiner Antwort durchgeführt, sonst könnte sie Die nicht angezeigt werden.
Es gibt die Möglichkeit, einen anderen Dateityp anzugeben.
Es gibt keine Unterstützung dieser Möglichkeit.
- Kann man [...] erzwingen
Warum wollt ihr eigentlich alle unbedingt Dinge "erzwingen"? Sowas hat im Internet nichts verloren - und deswegen geht es gewöhnlich auch nicht.
- Wenn nein, gibt es andere Möglichkeit (ich arbeite mit JSP)?
Ja. Archiv-Suche.
Cheatah
-
mhh... das war ja der mit Abstands sinnloseste post jemals von dir Cheatah...
TOM
-
Hi,
mhh... das war ja der mit Abstands sinnloseste post jemals von dir Cheatah...
ist es sinnlos jemandem beizubringen, wie er die Lösung zu seinem Problem findet?
Cheatah
-
Hi Tom,
mhh... das war ja der mit Abstands sinnloseste post jemals von dir
Cheatah...kann mir mal bei Gelegenheit jemand erklären, wieso Cheatah für seine fachlich makellosen Beiträge ständig gebashed wird und ich für dieselben Aussagen nicht?
Viele Grüße
Michael -
mhh... das war ja der mit Abstands sinnloseste post jemals von dir Cheatah...
TOM
ich kenne jetzt nicht alle posts von Cheatah und kann das schon daher nicht beurteilen ;-)
im ernst: an dieser "download erzwingen"-frage sind wir in anderen foren schon komplett gescheitert, ich habe damals keine lösung gefunden, in selfhtml habe ichs auch nicht verstanden.
und seit cheetahs post weiß ichs, der erste treffer im forums-archiv hat mir alle fragen beantwortet:
http://forum.de.selfhtml.org/archiv/2001/11/578/#m3389dankescnön.
schönen gruß, der gini.
-
-
Moin!
das Problem ist allseits bekannt. bei Klick auf einen HREf eines *.doc, *.pdf etc. -Dokuments, öffnet sich bei entsprechendem Plug-In die dazugehörige Anwendung. Ich will Dateien aber explizit zum Download anbieten - und ohne dem Hinweis "Rechter Mausklick...".
Es würde dir sicherlich helfen, wenn du verstehst, was auf dem Server, zwischen Server und Client und beim Client geschieht, wenn eine Ressource abgefordert wird.
Je nach Konfiguration nimmt der Server auch die Dateiendung als Hinweis, welche Art von Ressource vorliegt und welcher Mime-Typ dazugehört.
Jener Mime-Typ wird zusammen mit den Daten übermittelt.
Der Browser entscheidet anhand des Mime-Typs, welche Art von Daten vorliegen, und wie diese zu behandeln sind. Ausnahme: Der IE entscheidet bei den (angeblich - was aber nicht stimmt!) unspezifischen Mime-Typen "text/plain" und "application/octet-stream" anhand einiger Tests des Dateiinhalts, welcher Dateityp vorliegt (Link dazu sollte mit Suchwort "x-msdownload" im Archiv auffindbar sein).
Logischerweise ergibt sich aus vorstehender Schilderung: Wenn du das Verhalten des Clients beeinflussen willst, beeinflusse den Mime-Typ.
Es gibt die Möglichkeit, einen anderen Dateityp anzugeben.
... href="dummy.pdf" type="application/octet-stream"...Schwachsinnsangabe, die niemals funktionieren wird. Entscheidend ist, was der Server sagt, nichts anderes!
Fragen:
- Kann man mit JavaScript das Öffnen des "Speichern unter..."-Dialogs erzwingen (so wie print() das Drucken-Dialogfenster aufruft)?
Erzwingen läßt sich nichts.
- Wenn nein, gibt es andere Möglichkeit (ich arbeite mit JSP)?
Siehe oben: Mime-Typ ändern (wahlweise zentral serverweit statisch oder auch je Dokument skriptgesteuert dynamisch - ganz nach Wunsch).
- Sven Rautenberg
-
danke fuer die antworten!!
ad "müsst ihr denn immer alles erzwingen..."
1. wer ist "ihr"?
2.
ich will dem Benutzer "Ausdrucken" anbieten, damit er drucken kann
ich will dem Benutzer "Download" (was landläufig unter diesem Wort verstanden wird, von mir aus auch "diese-datei-an-einen-ort-freier-wahl-auf-der-lokalen-festplatte-speichern") anbieten, damit dieser downloaden kann
wenn ich das einem Benutzer anbiete, soll dies auch geschehen und nicht etwas anderes.beste gruesse uli
-
Hi,
ad "müsst ihr denn immer alles erzwingen..."
- wer ist "ihr"?
"Anfänger". Irgendwie stoße ich sehr oft auf Frager, die irgendwas erzwingen wollen - und meist stellen sie Fragen, die regelmäßig auftauchen.
ich will dem Benutzer "Ausdrucken" anbieten, damit er drucken kann
if (window.print) { window.print(); }
ich will dem Benutzer "Download" (was landläufig unter diesem Wort verstanden wird, von mir aus auch "diese-datei-an-einen-ort-freier-wahl-auf-der-lokalen-festplatte-speichern") anbieten, damit dieser downloaden kann
Das ist nur und ausschließlich durch serverseitige Aktion beeinflussbar.
wenn ich das einem Benutzer anbiete, soll dies auch geschehen und nicht etwas anderes.
Du kannst nichts erzwingen. Wenn _ich_ meinen Browser so konfiguriere, dass er die Daten in einen Hex-Editor schmeißt, ist das _meine_ Entscheidung. Wie Du am _wahrscheinlichsten_ das von Dir gewünschte Ergebnis erzeugst, hat Sven in der n-ten Wiederholung der Antwort beschrieben.
Cheatah
-
Moin Cheatah!
Wie Du am _wahrscheinlichsten_ das von Dir gewünschte Ergebnis erzeugst, hat Sven in der n-ten Wiederholung der Antwort beschrieben.
Es war die (n+1)-te, ich hab mitgezaehlt. ;-)
So long
--
Rule of thumb -- every time Microsoft use the word "smart," be on the lookout for something dumb.
-- http://www.fourmilab.ch/webtools/demoroniser/
-
Hi uli,
ad "müsst ihr denn immer alles erzwingen..."
wenn ich das einem Benutzer anbiete, soll dies auch geschehengenau das bedeutet eben "erzwingen".
Wenn Du etwas "anbietest", dann muß der Benutzer die Wahlmöglichkeit haben, dieses Angebot anzunehmen oder abzulehnen ... und genau das tut er mit Hilfe seiner Browser-Konfiguration.
Viele Grüße
Michael
-
-
Hallo Ulli,
eine Möglichkeit, die in vielen Browsern funktioniert, ist es, die Datei zu zippen, da dann automatisch das Downloadfenster angeboten wird. Vielleicht kennt einer der Kollegen eine Ausnahme. Ich benutze diese Lösung auch manchmal bei Fotos für Pressedownloads, obwohl das Zippen hier fast nichts bringt, weil die schreibenden Kollegen mit der angebotenen Auswahl besser umgehen können.
Viele Grüße
Mathias Bigge
-
Hi Matthias,
die Datei zu zippen, da dann automatisch das Downloadfenster
angeboten wird.Vielleicht wird aber auch ein Zip-Archiv-Programm aufgerufen, welches den Inhalt des Download-Dokuments automatisch öffnet und dem Benutzer anzeigt.
Oder ein Programm, welches den Download automatisch auf Viren prüft.
Oder was auch immer.
Genau deshalb ist dies ja im Browser konfigurierbar!Das alles ist eine Frage der Konfiguration des Browsers bzw. des Betriebssystems auf Client-Seite. Den Server geht es nichts an.
Der Server hat in HTTP das Recht, einen _Vorschlag_ für die empfohlene Art der Verarbeitung zu machen, nämlich den MIME-Typ. Mehr geht nicht.
Viele Grüße
Michael-
Stimmt Michael,
aber in den Standardeinstellungen fast aller Browser wird ein Download zumindest als Alternative angeboten. Mehr geht vielleicht wirklich auf dieser Ebene nicht, wie Du schon gesagt hast.
Viele Grüße
Mathias Bigge
-
-
-
Hallo an alle!
das Problem ist allseits bekannt. bei Klick auf einen HREf eines *.doc, *.pdf etc. -Dokuments, öffnet sich bei entsprechendem Plug-In die dazugehörige Anwendung. Ich will Dateien aber explizit zum Download anbieten - und ohne dem Hinweis "Rechter Mausklick...".
Es gibt die Möglichkeit, einen anderen Dateityp anzugeben.
... href="dummy.pdf" type="application/octet-stream"...
Funktioniert aber nicht bei IE, der liest tatsächlich die Dateiendung aus.
Fragen:- Kann man mit JavaScript das Öffnen des "Speichern unter..."-Dialogs erzwingen (so wie print() das Drucken-Dialogfenster aufruft)?
- Wenn nein, gibt es andere Möglichkeit (ich arbeite mit JSP)?
Moin Moin !
In meinem Projekt (CGI-basiert) mache ich das so:
if (user_wants_to_download()) {
print "Content-type: application/x-save-this-file\r\n\r\n";
} else {
print "Content-type: ",real_mime_type_of_the_file(),"\r\n\r\n";
}
print content_of_the_file();application/x-save-this-file ist:
* binärsicher ( --> application)
* nicht registriert ( --> x- = experimentell)
* gibt dem lesefähigen User einen Hinweis (--> "save-this-file")
* ansonsten völlig willkürlich gewählt, um mit keinem anderen MIME-Typen zu kollidierenuser_wants_to_download() kann z.B. einfach abfragen, ob in der URL ein Parameter "download" vorkommt (?download=0|1).
real_mime_type_of_this_file() liefert den "passenden" MIME-Type, also z.B. application/pdf.
content_of_the_file() liefert die eigentliche Datei.
Mein CGI benutzt diesen selbst erfundenen MIME-Typ konsequent, so daß User ihren Browser so einstellen können, daß Dateien mit diesem MIME-Typ automatisch gespeichert werden; der Browser fragt nur nach dem Dateinamen.
Du kannst sogar (außer beim IIS) den Dateinamen vorgeben, indem Du den Link passend machst:
http://meinserver/cgi-bin/meincgi.cgi/der-vorgegebene-dateiname.pdf?download=1;bla=fasel;laber=rhababer;
Der IIS sucht dann leider die Datei der-vorgegebene-dateiname.pdf im Verzeichnis(!!!) /cgi-bin/meincgi.cgi/. Kein anderer Webserver ist so "blöd", wenn es um das Zerlegen einer URL geht!
Wie schon andere hier bemerkten, benimmt sich der IE in Sachen MIME-Typen etwas daneben, eine URL, die auf .txt endet, wird IMMER als Text heruntergeladen und angezeigt, auch wenn der MIME-Typ z.B. image/jpeg ist.
Seltsam, daß immer die Microsoft-Produkte Probleme mit offenen Standards haben.
Alexander
-
Hi Alexander,
Wie schon andere hier bemerkten, benimmt sich der IE in Sachen
MIME-Typen etwas daneben, eine URL, die auf .txt endet, wird
IMMER als Text heruntergeladen und angezeigt, auch wenn der
MIME-Typ z.B. image/jpeg ist.
Seltsam, daß immer die Microsoft-Produkte Probleme mit offenen
Standards haben.tja, wenn es nur so wäre!
Es ist aber m. E. offensichtlich anders: M$ arbeitet nach Erwartungswert des Gesamtnutzens für die Anwender.Es gibt viel mehr falsch konfigurierte Server als Anwendungen, die darauf _angewiesen_ sind, ein Bild mit der Endung ".txt" anbieten zu können.
Konsequenterweise nimmt M$ an, daß es sich auf die Endung .txt (die dem Ersteller der Datei zweifellos bewußt ist) eher verlassen kann als auf die Konfiguration der MIME-Typen des Webservers (welche dem Seitenbastler praktisch nie zu Gesicht bekommen - oder, Chräcker? ;-).Meiner Meinung nach arbeitet der M$ _absichtlich_ fehlerhaft (d. h. im Widerspruch zum gültigen Standard), weil der Hersteller davon ausgeht, daß er damit mehr Fehler von Ahnungslosen repariert, als korrekte Anwendungen von Experten zu beschädigen.
(Bei der Interpretation von kaputtem HTML-Code ist es ja genauso.)Und abgesehen davon, daß dies statistisch gesehen sogar sinnvoll ist (falls man Attribute wie "Zuverlässigkeit" oder "Vorhersehbarkeit der Ergebnisse" etc. als irrelevant ansieht), ist auch noch festzuhalten, daß die solcherart "geschädigten" Profis ja immerhin genug Ahnung von der Materie haben, um auf diese bewußten Verstöße gegen die Standards zu reagieren - während die Ahnungslosen ihre eigenen Fehler ja weder erkennen noch gar beheben können.
So schrecklich es für einen Fan korrekt arbeitender Software sein mag: An der Philosophie von M$ ist gerade in der Welt des WWW mit "everyone's a publisher" (egal, mit welchem Basiswissen) leider durchaus etwas dran ...
Viele Grüße
Michael-
Moin!
tja, wenn es nur so wäre!
Es ist aber m. E. offensichtlich anders: M$ arbeitet nach Erwartungswert des Gesamtnutzens für die Anwender.Was ist der Gesamtnutzen, wenn ein Browser schlicht Informationen, die gewollt sein könnten, ignoriert?
Es gibt viel mehr falsch konfigurierte Server als Anwendungen, die darauf _angewiesen_ sind, ein Bild mit der Endung ".txt" anbieten zu können.
Öhm, das Problem ist, daß Microsoft durch dieses zwar publizierte, aber nicht bekannte Verhalten seines Browsers extrem viel Schaden anrichtet. Fehlerhafte Konfigurationen (so es sie denn für so grundlegende Dinge wie text/plain wirklich gibt) von Webservern werden mit dem IE eben nicht erkannt, weil beispielsweise HTML-Quelltext, der mit der Dateiendung .txt gespeichert wurde und vom Server wunschgemäß (dem Ersteller ist hierbei _nicht_ bewußt, was er da macht!) mit Mime-Typ text/plain ausgeliefert wird - der IE zeigt die HTML-Seite, alle anderen, standardkonformen Browser zeigen den Quelltext.
Konsequenterweise nimmt M$ an, daß es sich auf die Endung .txt (die dem Ersteller der Datei zweifellos bewußt ist) eher verlassen kann als auf die Konfiguration der MIME-Typen des Webservers (welche dem Seitenbastler praktisch nie zu Gesicht bekommen - oder, Chräcker? ;-).
Da kann sich der IE nicht drauf verlassen, denn wie oben dargelegt: Manche DAUs kriegen es eben hin, HTML-Dateien mit .txt-Endung abzuspeichern und hochzuladen - und dank IE sieht alles in Ordnung aus.
Meiner Meinung nach arbeitet der M$ _absichtlich_ fehlerhaft (d. h. im Widerspruch zum gültigen Standard), weil der Hersteller davon ausgeht, daß er damit mehr Fehler von Ahnungslosen repariert, als korrekte Anwendungen von Experten zu beschädigen.
Wenn etwas fehlerhaft arbeitet, ist es kaputt. Dabei ist egal, ob es absichtlich oder unabsichtlich geschehen ist: Kaputt ist kaputt und gehört repariert.
(Bei der Interpretation von kaputtem HTML-Code ist es ja genauso.)
Richtig, aber doch etwas anderes: Würden alle Browser sich streng nach Standard richten, gäbe es auch keinerlei fehlerhafte HTML-Seiten - weil die Ersteller die Probleme sofort sehen würden und korrigieren könnten. Statt irgendwas darzustellen könnte im Debug-Modus lieber eine Fehlermeldung ausgegeben werden - alle Programmiersprachen, egal ob Interpretersprache oder Compilersprache, kriegen das doch auch hin. Oder kannst du dir vorstellen, daß z.B. der Perl-Interpreter plötzlich fehlertolerant wird und nicht abgeschlossene Zeichenketten automatisch irgendwie repariert? Böse Fallen würden sich auftun, wenn aus Versehen Quellcode im Browser zu sehen wäre, weil keine Fehlermeldung kommt, sondern ruminterpretiert wird.
- Sven Rautenberg
-
Hallo Sven,
Was ist der Gesamtnutzen, wenn ein Browser schlicht Informationen,
die gewollt sein könnten, ignoriert?Der Gesamtnutzen ist die Menge der Verbesserungen minus der Höhe des angerichteten Schadens.
Beides unterliegt natürlich subjektiven Bewertungsfunktionen; meiner
Ansicht nach glaubt M$, daß ein positiver Wert heraus kommt.Ich halte das Vorgehen von M$ nicht für dilettantisch, sondern für
ertragsorientiert. (Es obliegt _Deiner_ Bewertungsfunktion, was Du
subjektiv als "schlimmer" empfinden magst ...)Öhm, das Problem ist, daß Microsoft durch dieses zwar publizierte,
aber nicht bekannte Verhalten seines Browsers extrem viel Schaden
anrichtet.Das ist _Deine_ Anwendung einer Bewertungsfunktion auf den Tatbestand.
Der Schaden für die Firma, für die ich arbeite, ist jedenfalls kleiner
als die Zusatzkosten für das "Kröten-Töten".Und nein, ich bin natürlich _kein_ Fan des M$IE. Es ist nur einfach so,
daß es seit etwas zwei Jahren überhaupt _keinen_ Browser mehr gibt,
der "funktioniert" - in dem Maße, wie ich das bräuchte.
(Deshalb hoffe ich ja, daß so ab 2003 oder 2004 der Mozilla diese Lücke
schließen wird - nicht nur bei den Freaks, sondern bei unseren erzkon-
servativen Firmenkunden.)Fehlerhafte Konfigurationen (so es sie denn für so grundlegende Dinge
wie text/plain wirklich gibt) von Webservern werden mit dem IE eben
nicht erkannt, weil beispielsweise HTML-Quelltext, der mit der
Dateiendung .txt gespeichert wurde und vom Server wunschgemäß (dem
Ersteller ist hierbei _nicht_ bewußt, was er da macht!) mit Mime-Typ
text/plain ausgeliefert wird - der IE zeigt die HTML-Seite, alle
anderen, standardkonformen Browser zeigen den Quelltext.Ich habe nicht ausgeschlossen, daß solche Fälle vorkommen. Und ich habe
mich selbst auch oft genug darüber geärgert.
Der Satz "nimm doch einen Browser und nicht diese Betriebssystemerwei-
terung" fällt bei uns im Büro jeden Tag mindestens einmal. Nur darf ich
das zwar meinen Kollegen sagen, nicht aber den Mitarbeitern der Bank,
welche das Konto verwalten, auf dem Dein Gehalt gespeichert ist ...
da ist nix mit "mal eben Mozilla installieren". (Alleine die Genehmi-
gung für ein solches Vorhaben dauert so lange, daß der Browser bis dahin
völlig veraltet wäre.)Da kann sich der IE nicht drauf verlassen, denn wie oben dargelegt:
Manche DAUs kriegen es eben hin, HTML-Dateien mit .txt-Endung
abzuspeichern und hochzuladen - und dank IE sieht alles in Ordnung aus.Es nützt nichts, wenn Du dieselben Nuancen des Problems im Detail wieder
und wieder aufzählst. Deshalb tue ich es nicht mit den gegenteiligen Fällen.Meiner Meinung nach arbeitet der M$ _absichtlich_ fehlerhaft.
Wenn etwas fehlerhaft arbeitet, ist es kaputt. Dabei ist egal, ob es
absichtlich oder unabsichtlich geschehen ist: Kaputt ist kaputt und
gehört repariert.Wären alle Beteiligten sich bei der Semantik der verwendeten Begriffe
einig, dann würde ich Dir zustimmen.Das sind sie aber natürlich nicht. Denn in meiner obigen Aussage könnte
ich den Begriff "fehlerhaft" ohne Änderung der Semantik (!) durch
"abweichend vom Standard" oder auch "kreativ-intelligent" ersetzen.
Nun rate mal, wessen Standpunkt ich damit ausdrücken würde ...Und Du wirst es schwer haben, M$ davon zu überzeugen, etwas zu reparieren,
was "kreativ-intelligent" arbeitet und mehr Webseiten "brauchbar" anzeigt
als andere Browser. So einfach ist das nicht mit der Logik, wenn man sich
über die Axiome nicht einig ist.(Bei der Interpretation von kaputtem HTML-Code ist es ja genauso.)
Richtig, aber doch etwas anderes: Würden alle Browser sich streng nach
Standard richten, gäbe es auch keinerlei fehlerhafte HTML-SeitenRichtig. Aber von einer unrealistischen These aus kannst Du alles und
nichts folgern. Das bringt die Diskussion nicht weiter.weil die Ersteller die Probleme sofort sehen würden und korrigieren
könnten.Dem stimme ich _nicht_ zu.
Denn Du setzt voraus, daß alle (oder auch nur die Mehrzahl!) Seiten-
ersteller so arbeiten wie Du.Ich denke, die Erzeugung von korrektem Code durch die WYSIWYG-Editoren
würde mindestens ebenso viel nutzen wie das Erzwingen des standard-
konformen Verhaltens aller Browser. (Nicht, daß es realistischer wäre,
_das_ zu fordern - solange auch bei den Generatoren "coole features"
bessere Verkaufsargumente sind als die Generierung validen Codes ...)Wieso sollte ich HTML-Code in irgendeinem Browser ansehen und "testen"
müssen? Eigentlich _sollte_ mir egal sein dürfen, ob die Browser korrekt
arbeiten oder nicht - wenn mein Code korrekt ist, dann ist er korrekt.
Ich als Entwickler würde es als völlig naheliegend empfinden, Code nur
in validierter Form auszuliefern - schon alleine deshalb, weil ich dann
im Falle einer Kundenbeschwerde nachweisen kann, daß es am kaputten Brow-
ser des Kunden liegt und nicht an meiner Seite (d. h. daß der Kunde die
Wahl hat, entweder einen funktionsfähigen Browser zu installieren oder
uns den "Sonderwunsch", die Seite auch mit seiner kaputten Software be-
nutzbar zu machen, wenigstens bezahlen muß).
In dieser Hinsicht interessiert mich herzlich wenig, ob eine Seite in
"allen" Browsern "läuft"; was mich interessiert, das ist, ob eine Seite
in denjenigen Browsern läuft, für die Verträge mit Firmenkunden vorliegen.Dies alles sei nicht als Richtlinie für einen "empfohlenen Arbeitsstil"
genannt - ich habe auch bewußt einiges überzeichnet, nur um klar zu ma-
chen, wie viele verschiedene Blickwinkel es für das Problem der Erstel-
lung "korrekter" Seiten neben demjenigen des W3C noch geben kann.Statt irgendwas darzustellen könnte im Debug-Modus lieber eine
Fehlermeldung ausgegeben werden - alle Programmiersprachen, egal ob
Interpretersprache oder Compilersprache, kriegen das doch auch hin.Richtig. Aber Du bist Dir doch hoffentlich bewußt, wie klein der Pro-
zentsatz der compile-link-go-erprobten Programmierer an der Gesamt-
menge der Seitenbastler ist?Und der Verbreitungsgrad des M$IE _ist_ nun mal ein Argument!
Die Nachfolgeversion des Produkts, mit dem ich arbeiten muß, wird nur
noch den M$IE unterstützen ... alles, was ich tun kann, ist, Munition
zu sammeln, um ein Upgrade zu verhindern.Ich komme immer wieder darauf zurück, daß Du Dich selbst zu sehr als
Maßstab siehst und daß Dich dies glauben läßt, Maßstaben pushen zu
wollen, die in einer Welt aus lauter Informatikern (wie mir) großartig
wären. In einer Welt voller kommerziellen Interessen jedoch ...Oder kannst du dir vorstellen, daß z.B. der Perl-Interpreter plötzlich
fehlertolerant wird und nicht abgeschlossene Zeichenketten automatisch
irgendwie repariert?Natürlich könnte ich das. Sind Programmiersprachen wie SQL nicht eigent-
lich der Versuch, die Software-Entwicklung in eine Richtung zu bringen,
in der weniger die Syntax und mehr die Semantik im Vordergrund steht?Und eine Firma, die einen solchen Interpreter verkaufen würde und damit
die Entwicklungskosten von rapid prototyping für die Anwender spürbar
senken würde, könnte eine Menge Geld damit verdienen!
Daß qualitätsbewußte Entwickler wie Du ihre Programme weiterhin "vali-
dieren" würden, ist ja kein Widerspruch dazu, daß es Anwender gibt,
die das nicht tun würden, weil sie glauben, damit besser zu fahren.Alles, wofür Nachfrage existiert und was nicht durch Gesetze etc. wir-
kungsvoll verhindert wird, tummelt sich früher oder später auf dem Markt.Böse Fallen würden sich auftun, wenn aus Versehen Quellcode im Browser
zu sehen wäre, weil keine Fehlermeldung kommt, sondern ruminterpretiert
wird.Eine Idee ist nicht alleine deshalb schlecht, weil man damit auch böse
Dinge tun können. Kennst Du denn eine einzige gute Idee, mit der man
nichts Böses anfangen kann?Deshalb habe ich meinen Beitrag mit der Betrachtung des Gesamtnutzens
begonnen - und ich schließe ihn auch damit.Viele Grüße
Michael
(der sich den Spaß leistet, demnächst ein Skript als Open Source zu pub-
lizieren, das XHTML 1.1 erzeugt ... aber beruflich Seiten baut, die
nicht mal ein DOCTYPE-Statement haben und auch keines verdienen würden)-
Hallo Sven, hallo Michael,
ich glaube Michaels Kernargument der wirtschaftlichen Realitäten überzeugt viele Praktiker: Von meinen Auftraggebern würde eine Seite, die im IE 5.X und 6.X nicht korrekt angezeigt wird, nicht abgenommen, auch wenn dort durchaus Leute sitzen, die wissen, woran es liegt. Interessant wäre etwa auch die Frage, wie man im Falle einer juristischen Klärung dastände, wenn man den Nachweis führen kann, dass alles den offiziellen Standards entspricht. Aber auch diese Frage hat eher akademischen Charakter, jeder Praktiker weiß warum.
An Sven würde ich vor allem die Frage stellen, ob er uns - ich gebrauche hier bewusst die 1. Person Plural, denn ich denke, wir sind alle für verlässliche Standards - für stark genug hält, in dieser Richtung eine wirkungsvolle pressure group zu sein?
Ich halte das Vorgehen von M$ nicht für dilettantisch, sondern für
ertragsorientiert.Richtig, und der Erfolg gibt ihnen irgendwie Recht.
Und nein, ich bin natürlich _kein_ Fan des M$IE. Es ist nur einfach so,
daß es seit etwas zwei Jahren überhaupt _keinen_ Browser mehr gibt,
der "funktioniert" - in dem Maße, wie ich das bräuchte.Mal ehrlich, vorher war's doch auch nicht besser!? Und bei allem Ärger über die Monopoli-Allüren der Redmonter - eine Seite auf dem IE ans Laufen zu bringen ist doch meistens nicht der große Problempunkt bei der Entwicklung. Da haben mir die unterschiedlichen Katastrophen im Zuge der 4.X-Versionen beim Netscape weitaus mehr Kopfschmerzen gemacht.
Der Satz "nimm doch einen Browser und nicht diese Betriebssystemerwei-
terung" fällt bei uns im Büro jeden Tag mindestens einmal. Nur darf ich
das zwar meinen Kollegen sagen, nicht aber den Mitarbeitern der Bank,
welche das Konto verwalten, auf dem Dein Gehalt gespeichert ist ...
da ist nix mit "mal eben Mozilla installieren".Welchen klaren und verlässlichen Zusatznutzen hat zum Beispiel der Mozilla für eine Firma, um damit eine Installation plus Plugins und Wartung auf zahlreichen Rechnern zu legitimieren? Schon bei den Themen "Geschwindigkeit", "Automatisierung der Installation" und "Multimedia-Einbindung" käme man m.E. in Argumentationsschwierigkeiten.
Auch im Bereich der Betriebssysteme, wo es klarere Argumente für Unix-Derivate und andere Open Source Produkte gibt, hat sich so eine Mentalität eingeschlichen, dass es auf dem aktuellen Microsoft-System am Einzelarbeitsplatz schon irgendwie laufen wird, und dass es angesichts der Größe der Nutzergemeinde schon für jeden trouble einen shooter geben wird. Dabei kümmert sich schon gar nicht mehr wirklich um die Details, sondern nimmt bestimmte Probleme als gottgegeben hin - und verläßt sich auf die oben angesprochene Fehlertoleranz der Microsoft-Systeme.
Das größte Argument für die Windows Varianten sind dabei vor allem:
- Einbindung auch exotischer Hardware geht (fast) immer
- Datenaustausch zwischen Programmen und Versionen ist fast immer leicht zu machen
- geringe Einarbeitungszeit
- Einbindung jeweiliger Spezialanwendungen in die Office-Umgebung
- Fehlertoleranz (!)
Michael hat diese Sicht der Dinge treffend ausgedrückt:
Denn in meiner obigen Aussage könnte
ich den Begriff "fehlerhaft" ohne Änderung der Semantik (!) durch
"abweichend vom Standard" oder auch "kreativ-intelligent" ersetzen.Interessant finde ich auch eure Diskussion zur Haltung auf der Produzentenseite. Ich glaube wie Michael, dass immer noch sehr wenige Entwickler ihre Sites wirklich systematisch testen und validieren wie den Code einer echten Programmiersprache, sondern viel eher, auch aus Zeitdruck natürlich, herumwurschteln, und grenzenlos dankbar sind, wenn der IE das wunderbar schluckt.
Ich habe mich auch erst durch die Diskussionen hier im Forum und von Leuten wie Sven davon überzeugen lassen, dass es sich lohnt, strukturierter und valide vorzugehen. Aber erst nachdem ich mal sehr konsequent ein mittleres Projekt auf valide Beine gestellt habe, bin ich davon überzeugt, dass es sich wirklich lohnt, schon allein aufgrund der verbesserten Wartbarkeit. Vorher fand ich zwar einige Argumente nachvollziehbar, die Verehrer des Validators erschienen mir aber oft als verbiesterte Prinzipienreiter ohne Kenntnis der Realitäten, und einige sind es ja vielleicht auch wirklich ;-)
Nur bei bestimmten Design-Vorgaben, etwa zentriert aufgebauten Seiten, finde ich konsequente CSS-Lösungen zum Teil schwer für alle Browser realisierbar, aber vielleicht fehlen mir da zum Teil nur noch die richtigen Kniffe.
Oder kannst du dir vorstellen, daß z.B. der Perl-Interpreter plötzlich
fehlertolerant wird ... ?Natürlich könnte ich das. Sind Programmiersprachen wie SQL nicht eigent-
lich der Versuch, die Software-Entwicklung in eine Richtung zu bringen,
in der weniger die Syntax und mehr die Semantik im Vordergrund steht?Stimmt, die fehlertolerante Verarbeitung von Abfragen im Datenbankbereich war vielleicht wirklich erst der Beginn. Und ich bin sogar sicher, dass gerade auch im Perl-Konzept von Anfang an so etwas wie Fehlertoleranz "eingebaut" wurde.
Deshalb habe ich meinen Beitrag mit der Betrachtung des Gesamtnutzens
begonnen - und ich schließe ihn auch damit.Es ist, wie es ist. Ob's auch gut so ist, da bin ich mir nicht so sicher. Aber den Aspekt der Fehlertoleranz finde ich sehr interessant, vor allem in Hinsicht auf Konzepte, die eine gewisse Bandbreite von Abweichungen oder Ungenauigkeiten zu verarbeiten versuchen, ohne dabei unvorhersagbare Ergebnisse zu produzieren. Ich glaube, gerade Perl, das Sven nicht zufällig als Beispiel für die hardcore-Abteilung der Webprogrammierung genannt hat, kann nur in der "strict"-Variante -T argumentatorisch ins Feld geführt werden.
Vielleicht auch ein nettes *g*: "Perl als der IE unter den Programmiersprachen" ;-) (Ja, ja, ich weiß, nehme auch alles sofort zurück......)
Viele Grüße
Mathias Bigge
-
Moin, Mathias!
ich glaube Michaels Kernargument der wirtschaftlichen Realitäten überzeugt viele Praktiker: Von meinen Auftraggebern würde eine Seite, die im IE 5.X und 6.X nicht korrekt angezeigt wird, nicht abgenommen, auch wenn dort durchaus Leute sitzen, die wissen, woran es liegt.
Natürlich ist das wirtschaftliche Argument immer das stärkere, aber dabei sollte man bitte nicht abschweifen:
Was hat es für einen Sinn, daß der IE dem Mime-Typ "text/plain" nicht traut, sondern speziell untersucht und ggf. je nach gefundenem Dateiinhalt darstellt? Hat es einen wirtschaftlichen Sinn? Nein, kann ich nicht finden. Es produziert Extrakosten, weil für ganz alltägliche Probleme (hier: Download erzwingen) die offensichliche Lösung (hier: Mime-Typ verändern) nicht greifen - und das zu allem Überfluß ausgerechnet im verbreitetsten alles Browser -, so daß zusätzlicher Rechercheaufwand nötig ist. Und mal ganz im Ernst: Helfen tut's eigentlich niemandem.
Aber da wir das Thema gerade so schön allgemein beleuchten... :)
An Sven würde ich vor allem die Frage stellen, ob er uns - ich gebrauche hier bewusst die 1. Person Plural, denn ich denke, wir sind alle für verlässliche Standards - für stark genug hält, in dieser Richtung eine wirkungsvolle pressure group zu sein?
Ich denke schon, daß das SelfForum, aber vor allem SelfHTML, einen sehr sehr großen Einfluß auf die HTML-schreibenden Personen des deutschsprachigen Raumes hat. Insofern wird sich das Schreiben von validen und sinnvoll strukturierten Seiten irgendwann durchsetzen. Und zu diesem Zeitpunkt werden auch Browser zur Verfügung stehen, die sowas umsetzen und verstehen können.
Ich halte das Vorgehen von M$ nicht für dilettantisch, sondern für
ertragsorientiert.Richtig, und der Erfolg gibt ihnen irgendwie Recht.
Ich denke, die Detailfrage des Mime-Typs dürfte keinesfalls entscheidend gewesen sein, daß der IE eine derartige Verbreitung gefunden hat. :)
- Sven Rautenberg
-
-
-