Montag, 27. September 2010
IE und Buttons in Formularen
Wie kann ein Browser nur so ignorant sein:http://www.fourmilab.ch/fourmilog/archives/2007-03/000824.html
Deshalb haben wir das in unserem Forward-DNS-Editor auch gleich mal angeprangert:
Trackbacks
Trackback-URL für diesen Eintrag
Keine Trackbacks
Kommentare
Ansicht der Kommentare:
(Linear | Verschachtelt)
Habe ich bei einem privaten Projekt auch lange so verfolgt ... und es ging etlichen Usern gewaltig auf die Nerven und es zeugt nicht gerade von Professionalität (späte Einsicht).
Habe das damals so gelöst, dass ich per Browserweiche die 'brauchbaren' Browser mit dem gewünschten Formular gefüttert habe und die 'unbrauchbaren' (IE, Netscape, Opera, etc) mit einem 08/15 Formular beglückt habe. Darüber ein entsprechender Hinweis, dass aufgrund des verwendeten Browsers die Ansicht abweichen kann.
Konnten alle gut damit leben
. Denk mal drüber nach.
Habe das damals so gelöst, dass ich per Browserweiche die 'brauchbaren' Browser mit dem gewünschten Formular gefüttert habe und die 'unbrauchbaren' (IE, Netscape, Opera, etc) mit einem 08/15 Formular beglückt habe. Darüber ein entsprechender Hinweis, dass aufgrund des verwendeten Browsers die Ansicht abweichen kann.
Konnten alle gut damit leben
. Denk mal drüber nach.
Ich denke, kommt auch ein bisschen darauf an, ob es eine Funktion für den 08/15-User ist (bei dem halt durchaus ein IE im Einsatz sein kann), oder für Leute, die eine Ahnung von der Materie haben (was beim Bearbeiten von irgendetwas, das mit DNS zu tun hat, wohl der Fall sein wird; und diese Leute werden [hoffentlich] eher einen 'brauchbaren' Browser im Einsatz haben)…
Unprofessionell ist hier imho nur der Hersteller des defekten Browsers.
ACK!
Und: Wir richten unsere Produkte bewusst an professionelle Anwender. Wer den IE einsetzt und trotz dieser "Bugs" darauf beharrt, gehört nicht zu unserer Zielgruppe.
Wer den IE mag, ebenso aber unser Tool nutzen möchte, und zudem professionell arbeitet, hat vermutlich mehr als einen Browser installiert. Ergo kein Problem
Und: Wir richten unsere Produkte bewusst an professionelle Anwender. Wer den IE einsetzt und trotz dieser "Bugs" darauf beharrt, gehört nicht zu unserer Zielgruppe.
Wer den IE mag, ebenso aber unser Tool nutzen möchte, und zudem professionell arbeitet, hat vermutlich mehr als einen Browser installiert. Ergo kein Problem
Natürlich gibt es eine serverseitige Lösung des Problems, nämlich alle benötigten Daten im Namen des Buttons zu kodieren und den Wert nur für das Label zu verwenden.
Man legt dann einfach einen Kompatibilitätslayer in die Formulardaten-Verarbeitung, der aus dem Button-Namen die Werte extrahiert und die entsprechenden Parameter erzeugt.
Um (ganz schamlos) etwas Werbung zu machen - Im OSS-Web-Framework Pustefix (http://www.pustefix-framework.org/) ist das seit Jahren implementiert, so dass man in einer Seiten-Definition innerhalb eines Buttons beliebige Parameter-Wert-Paare angeben kann. Das Framework übernimmt dann die Kodierung in und die Extraktion aus dem Button-Namen.
Genau genommen werden nicht die Informationen im Button-Namen kodiert, sondern der Button-Name über eine generierte Id mit einen Hidden-Formular-Feld korreliert, das dann die Informationen enthält. Ein relativ einfacher Ansatz, der hervorragend funktioniert.
Wenn ihr an der Implementierung interessiert seit: Der für den View relevante Code, welcher die Erzeugung des Hidden-Feldes übernimmt befindet sich in http://dev.pustefix-framework.org/browser/trunk/pustefix-core/src/main/resources/PUSTEFIX-INF/xsl/forminput.xsl ab Zeile 259 bzw. wird vom Button-Template, das ab Zeile 324 beginnt in Zeile 364 aufgerufen.
Die Logik zur Formulardaten-Verarbeitung befindet sich im wesentlichen in http://dev.pustefix-framework.org/browser/trunk/pustefix-core/src/main/java/de/schlund/pfixxml/PfixServletRequestImpl.java ab Zeile 422.
Da das LGPL-Code ist, dürfte abgucken in Ordnung sein.
Man legt dann einfach einen Kompatibilitätslayer in die Formulardaten-Verarbeitung, der aus dem Button-Namen die Werte extrahiert und die entsprechenden Parameter erzeugt.
Um (ganz schamlos) etwas Werbung zu machen
- Im OSS-Web-Framework Pustefix (http://www.pustefix-framework.org/) ist das seit Jahren implementiert, so dass man in einer Seiten-Definition innerhalb eines Buttons beliebige Parameter-Wert-Paare angeben kann. Das Framework übernimmt dann die Kodierung in und die Extraktion aus dem Button-Namen.Genau genommen werden nicht die Informationen im Button-Namen kodiert, sondern der Button-Name über eine generierte Id mit einen Hidden-Formular-Feld korreliert, das dann die Informationen enthält. Ein relativ einfacher Ansatz, der hervorragend funktioniert.
Wenn ihr an der Implementierung interessiert seit: Der für den View relevante Code, welcher die Erzeugung des Hidden-Feldes übernimmt befindet sich in http://dev.pustefix-framework.org/browser/trunk/pustefix-core/src/main/resources/PUSTEFIX-INF/xsl/forminput.xsl ab Zeile 259 bzw. wird vom Button-Template, das ab Zeile 324 beginnt in Zeile 364 aufgerufen.
Die Logik zur Formulardaten-Verarbeitung befindet sich im wesentlichen in http://dev.pustefix-framework.org/browser/trunk/pustefix-core/src/main/java/de/schlund/pfixxml/PfixServletRequestImpl.java ab Zeile 422.
Da das LGPL-Code ist, dürfte abgucken in Ordnung sein.
Ein kurzer Nachtrag, damit kein falscher Eindruck entsteht:
Auch ich hasse, wie der Internet-Explorer Standards nicht korrekt implementiert. Gefühlte 50% des hässlichen Codes in einem Web-Framework stammen von Workarounds um diverse Bugs zu umgehen. Der genannte Bug ist allerdings noch einer von den leicht umgehbaren.
Gemeiner ist ein Bug in der HTTP-Implementierung einer Microsoft-Anwendung, welcher dafür sorgt, dass Cookies in bestimmten Fällen gespeichert und mitgesendet werden und in anderen Fällen nicht, wohlgemerkt innerhalb der gleichen Sitzung. Wenn man dann Code hat, der prüft ob Cookies unterstützt werden (oder für das Session-Management ausschließlich die URL verwendet werden kann), kann dies zu sehr lustigen Fehlern führen. Natürlich gibt es auch für dieses Problem einen Workaround, aber der ist um einiges hässlicher als der Workaround für Werte in Abhängigkeit vom gedrückten Button.
Auch ich hasse, wie der Internet-Explorer Standards nicht korrekt implementiert. Gefühlte 50% des hässlichen Codes in einem Web-Framework stammen von Workarounds um diverse Bugs zu umgehen. Der genannte Bug ist allerdings noch einer von den leicht umgehbaren.
Gemeiner ist ein Bug in der HTTP-Implementierung einer Microsoft-Anwendung, welcher dafür sorgt, dass Cookies in bestimmten Fällen gespeichert und mitgesendet werden und in anderen Fällen nicht, wohlgemerkt innerhalb der gleichen Sitzung. Wenn man dann Code hat, der prüft ob Cookies unterstützt werden (oder für das Session-Management ausschließlich die URL verwendet werden kann), kann dies zu sehr lustigen Fehlern führen. Natürlich gibt es auch für dieses Problem einen Workaround, aber der ist um einiges hässlicher als der Workaround für Werte in Abhängigkeit vom gedrückten Button.
Solange Menschen fleißig Workarounds für den IE coden, wird es auch immer nötig sein, dass zu tun.
Wenn die IE Nutzer aufeinmal nur noch 20% des (nicht-pornografischen Teil) des Internets ordentlich betrachten können, wechseln die ganz hops den Browser
Ich vertrete knallhart die Meinung, auf solche Workarounds zu verzichten. Zumal es auch einiges an Geld des Kunden spart, bei einem Satz von 60€/h für Webentwicklung
Oder würdet ihr einen Drucker kaufen, bei dem das Verwenden von DIN-(A4) Papier nur durch einen Zusatz möglich wäre?
Von daher kann ich Manitu schon gut nachvollziehen
Wenn die IE Nutzer aufeinmal nur noch 20% des (nicht-pornografischen Teil) des Internets ordentlich betrachten können, wechseln die ganz hops den Browser
Ich vertrete knallhart die Meinung, auf solche Workarounds zu verzichten. Zumal es auch einiges an Geld des Kunden spart, bei einem Satz von 60€/h für Webentwicklung
Oder würdet ihr einen Drucker kaufen, bei dem das Verwenden von DIN-(A4) Papier nur durch einen Zusatz möglich wäre?
Von daher kann ich Manitu schon gut nachvollziehen
Das war mal ein wirklich netter Vergleich - den werde ich mir merken. Danke!
Natürlich muss man immer eine Abwägung zwischen Kosten und Nutzen treffen.
Bei einem rein privaten Projekt, würde ich wahrscheinlich auch auf einen solchen Workaround verzichten.
Wenn man mit dem Produkt aber Geld verdienen will, dürfte es meistens billiger kommen einen Workaround zu bauen, als die (potentiellen) Kunden, die den IE benutzen, zu verlieren. Das war zumindest der Grund, warum dieser Workaround bei meinem damaligen Arbeitgeber in das o.g. Framework eingebaut wurde. Das ist aus meiner Sicht auch einer der wichtigsten Gründe für ein Framework, nämlich solche Workarounds an zentraler Stelle einbauen zu können, so dass alle Applikationen davon profitieren, ohne dass sich der einzelne Anwendungsentwickler noch einmal damit befassen muss.
Ich kann aber die Gründe, warum man einen solchen Workaround nicht einbauen will, sehr gut nachvollziehen und will diese Entscheidung nicht werten. Letztendlich betrifft mich diese Entscheidung auch nicht, und umgekehrt würde ich mir von anderen auch nicht hereinreden lassen, wie ich meine Firma führe.
Ich bin einfach nur über den Satz "Aus technischen Gründen können wir von unserer Seite aus keine Änderungen vornehmen, um diesen Editor kompatibel zu gestalten" gestolpert und bin der Meinung, er müsste korrekterweise lauten: "Aus organisatorischen Gründen wollen wir von unserer Seite aus keine Änderungen vornehmen, um diesen Editor kompatibel zu gestalten." - vielleicht mit dem Zusatz "Benutzen Sie doch einfach einen Browser, der nicht jeden Web-Standard völlig verdreht interpretiert."
Bei einem rein privaten Projekt, würde ich wahrscheinlich auch auf einen solchen Workaround verzichten.
Wenn man mit dem Produkt aber Geld verdienen will, dürfte es meistens billiger kommen einen Workaround zu bauen, als die (potentiellen) Kunden, die den IE benutzen, zu verlieren. Das war zumindest der Grund, warum dieser Workaround bei meinem damaligen Arbeitgeber in das o.g. Framework eingebaut wurde. Das ist aus meiner Sicht auch einer der wichtigsten Gründe für ein Framework, nämlich solche Workarounds an zentraler Stelle einbauen zu können, so dass alle Applikationen davon profitieren, ohne dass sich der einzelne Anwendungsentwickler noch einmal damit befassen muss.
Ich kann aber die Gründe, warum man einen solchen Workaround nicht einbauen will, sehr gut nachvollziehen und will diese Entscheidung nicht werten. Letztendlich betrifft mich diese Entscheidung auch nicht, und umgekehrt würde ich mir von anderen auch nicht hereinreden lassen, wie ich meine Firma führe.
Ich bin einfach nur über den Satz "Aus technischen Gründen können wir von unserer Seite aus keine Änderungen vornehmen, um diesen Editor kompatibel zu gestalten" gestolpert und bin der Meinung, er müsste korrekterweise lauten: "Aus organisatorischen Gründen wollen wir von unserer Seite aus keine Änderungen vornehmen, um diesen Editor kompatibel zu gestalten." - vielleicht mit dem Zusatz "Benutzen Sie doch einfach einen Browser, der nicht jeden Web-Standard völlig verdreht interpretiert."
Nun ja, ich kann das ja verstehen, dass man sich über den IE aufregt. Aber in diesem speziellen Fall würde ich das nicht so eng sehen, es gibt genug elegante Möglichkeiten auch ohne das "value" im Button aus zukommen. Da spart man sich auch eine Menge Irritationen beim Kunden. Folgendes würde ich schon eher unterstützen: z.B. http://www.browser-update.org/
Mal ne andere Frage: Der Text ist ja vom März 2007 und redet von IE 6 und vom kommenden IE7 und ist damit eigentlich hoffnungslos veraltet. Verhält sich denn der aktuelle IE8 (und kommende IE9) immernoch so?
Hallo,
kann es sein, das es Firefox ab Version 4 das Gleiche Problem gibt ????
Ich habe da ein Problem mit einem Formular, das mit FF < Version 4 funktioniert. IE bis Version 7 zeigt das im Blog erwähnte Verhalten. FF ab Version 4 dann auch.
Gruß,
Jens
kann es sein, das es Firefox ab Version 4 das Gleiche Problem gibt ????
Ich habe da ein Problem mit einem Formular, das mit FF < Version 4 funktioniert. IE bis Version 7 zeigt das im Blog erwähnte Verhalten. FF ab Version 4 dann auch.
Gruß,
Jens
IPv4 vs. IPv6
Du bist hier via
Suche
Ökostrom
Kalender
Kommentare
zu Hochtourig
Sa, 26.05.2012 02:28
At present, many excellent pla
yers have already in big games
in adizero [url=http://www.newairyeezy2.com][b]kanye [...]
Sa, 26.05.2012 00:19
Naja die meisten Kunden sind h
alt keine Experten, wenn in me
inem Fenster eine Werbetafel e
röffnet werden würde, da [...]
Fr, 25.05.2012 23:17
http://blog.fefe.de/?ts=b14989
2a
Besser?
Zitat: "Micro
soft erwirkt Einfuhrstopp für
Android-Geräte von Motor [...]
Fr, 25.05.2012 19:46
Arbeit anderer 1:1 kopieren !=
dem was die Patenttrolle mome
ntan veranstalten.
Fr, 25.05.2012 18:54
Naja ne AGB ist ja auch schnel
l geschrieben, aber kaum wird
sie kopiert ist das geschrei g
roß
Do, 24.05.2012 21:20
Ich finde es nicht verwerflich
euch danach zu fragen.
Ihr h
abt halt einen super support!
Ich finde die Frage nic [...]
Do, 24.05.2012 20:37
Ich wuerde da weniger auf eine
n "Gesellen" im Browser tippen
, sondern eher auf ein gehackt
es Script auf seiner Web [...]
Do, 24.05.2012 19:14
Och,
ich empfinde das noch al
s relativ neutral. Und so frag
t er halt einfach nach bei dir
.
