PeterPawn
IPPF-Urgestein
- Mitglied seit
- 10 Mai 2006
- Beiträge
- 15,282
- Punkte für Reaktionen
- 1,754
- Punkte
- 113
- die BPjM-Liste ist immer noch zu überschreiben (Incident 460241, s. auch hier)
- Export-Problem (falsches Kennwort für die Export-Datei bei Verwendung von "Enter" im Kennwort-Eingabefeld) beseitigt ... allerdings auf die denkbar "dümmste" Art, die man sich vorstellen kann - so einen Unsinn habe ich lange nicht mehr gesehen (und entgegen meiner sonst eher zurückhaltenden Art der Bewertung drücke ich das mal ganz drastig und eindeutig aus, ohne wenn und aber); anstatt da eine ordentliche Behandlung durchzuführen, wird jetzt die "Enter"-Taste im betreffenden Formular gar nicht mehr erkannt, weil man einfach ein "dummy control" mit Typ "submit" definiert hat, was generell die Behandlung eines "submit"-Events abwürgt mit einem "return false;":
OT:
Ich weiß nicht, ob da mal ein Praktikant an den Code durfte oder ob die Leute dank der ganzen Frameworks heute wirklich alle keine Ahnung mehr davon haben, wie JS im Browser intern arbeitet und was man unter "event bubbling" versteht bzw. wie man selbst eine passende Behandlung auslösen kann. Aber wenn da ein "return false" anstelle des Aufrufs des richtigen Eventhandlers (notfalls mit einen Event-Objekt, das man selbst erstellt) steht, dann fällt (meiner Meinung nach) jedem halbwegs ordentlichen Programmierer vor lauter Lachen das Essen aus dem Gesicht. Auch eine passende "keydown"-Behandlung für "keyCode == 13" sollte das ermöglichen ... es gibt praktisch so viele Wege, so etwas zu lösen, daß dieses "dummy control" schon fast wieder witzig wirkt. Das erinnert mich an so etwas: http://www.heise.de/autos/artikel/D...turen-1717729.html?bild=26;view=bildergalerie ... die Vermutung mit dem Praktikanten befällt mich auch deshalb, weil da das Submit-Control tatsächlich durch lustige X/Y-Koordinaten "versteckt" wird anstatt die dafür vorgesehenen HTML/CSS-Mechanismen zu verwenden. Wenn das wirklich ein "ausgewachsener Programmierer" gewesen sein sollte, wird mir erst so richtig bange, wenn ich an künftige "Code-Qualität" bei AVM denke. Das sieht irgendwie mehr nach einer Suche im Internet und Übernahme eines obskuren Tipps von "stackoverflow.com" aus, als nach jemandem, der sich mit der Materie auch wirklich auskennt. Hier erlaube ich mir mal ein beherztes "Pfui" und ein "Sechs, setzen!" als Kommentar. Wer selbst mit JS-Frameworks und/oder HTML bzw. CSS umgehen kann, wird mir (vermutlich oder zumindest hoffentlich) zustimmen - die hier "gefundene" Lösung sorgt nämlich auch noch für einen "Bruch" in der UX - daß die "Enter"-Taste eine Eingabe beendet und zumindest den Fokus zum nächsten Eingabefeld verschiebt oder sogar das Formular entsprechend absendet, ist das Verhalten so ziemlich jedes "normalen" Programms und jeder beliebigen Webseite; bei anderen Formularen im AVM-GUI ist das ja auch nicht anders. Das macht diese "Lösung" zur Flickschusterei - daß es auch anders geht, kann man sich z.B. in der Benutzerverwaltung im FRITZ!OS ansehen.
- verwaiste Links in der Übersicht korrigiert
- den JS-(Schönheits-)Fehler beim Ändern der FTP-Portnummer für den externen Zugriff findet bestimmt auch noch jemand
- der Mediaserver erlaubt ebenfalls noch den unbeschränkten Lese-Zugriff auf jede einzelne Datei, unabhängig vom Inhaltsverzeichnis und sonstigen NAS-Einstellungen ... ich habe die Hoffnung auch begraben, daß sich daran jemals etwas ändern wird
- - - Aktualisiert - - -
Die Thematik der "Vermischung" der Namensräume von DNS (fritz.box) und mDNS (local) hat AVM aber immer noch nicht angepackt:
und nach wie vor erhält ein Client im LAN bei der entsprechenden Abfrage auch von der FRITZ!Box die passende Antwort:
- Export-Problem (falsches Kennwort für die Export-Datei bei Verwendung von "Enter" im Kennwort-Eingabefeld) beseitigt ... allerdings auf die denkbar "dümmste" Art, die man sich vorstellen kann - so einen Unsinn habe ich lange nicht mehr gesehen (und entgegen meiner sonst eher zurückhaltenden Art der Bewertung drücke ich das mal ganz drastig und eindeutig aus, ohne wenn und aber); anstatt da eine ordentliche Behandlung durchzuführen, wird jetzt die "Enter"-Taste im betreffenden Formular gar nicht mehr erkannt, weil man einfach ein "dummy control" mit Typ "submit" definiert hat, was generell die Behandlung eines "submit"-Events abwürgt mit einem "return false;":
Code:
<input type="submit" value="" style="position:absolute;top:-9999px;left:-9999px;" name="dummyenter" onclick="return false;">Ich weiß nicht, ob da mal ein Praktikant an den Code durfte oder ob die Leute dank der ganzen Frameworks heute wirklich alle keine Ahnung mehr davon haben, wie JS im Browser intern arbeitet und was man unter "event bubbling" versteht bzw. wie man selbst eine passende Behandlung auslösen kann. Aber wenn da ein "return false" anstelle des Aufrufs des richtigen Eventhandlers (notfalls mit einen Event-Objekt, das man selbst erstellt) steht, dann fällt (meiner Meinung nach) jedem halbwegs ordentlichen Programmierer vor lauter Lachen das Essen aus dem Gesicht. Auch eine passende "keydown"-Behandlung für "keyCode == 13" sollte das ermöglichen ... es gibt praktisch so viele Wege, so etwas zu lösen, daß dieses "dummy control" schon fast wieder witzig wirkt. Das erinnert mich an so etwas: http://www.heise.de/autos/artikel/D...turen-1717729.html?bild=26;view=bildergalerie ... die Vermutung mit dem Praktikanten befällt mich auch deshalb, weil da das Submit-Control tatsächlich durch lustige X/Y-Koordinaten "versteckt" wird anstatt die dafür vorgesehenen HTML/CSS-Mechanismen zu verwenden. Wenn das wirklich ein "ausgewachsener Programmierer" gewesen sein sollte, wird mir erst so richtig bange, wenn ich an künftige "Code-Qualität" bei AVM denke. Das sieht irgendwie mehr nach einer Suche im Internet und Übernahme eines obskuren Tipps von "stackoverflow.com" aus, als nach jemandem, der sich mit der Materie auch wirklich auskennt. Hier erlaube ich mir mal ein beherztes "Pfui" und ein "Sechs, setzen!" als Kommentar. Wer selbst mit JS-Frameworks und/oder HTML bzw. CSS umgehen kann, wird mir (vermutlich oder zumindest hoffentlich) zustimmen - die hier "gefundene" Lösung sorgt nämlich auch noch für einen "Bruch" in der UX - daß die "Enter"-Taste eine Eingabe beendet und zumindest den Fokus zum nächsten Eingabefeld verschiebt oder sogar das Formular entsprechend absendet, ist das Verhalten so ziemlich jedes "normalen" Programms und jeder beliebigen Webseite; bei anderen Formularen im AVM-GUI ist das ja auch nicht anders. Das macht diese "Lösung" zur Flickschusterei - daß es auch anders geht, kann man sich z.B. in der Benutzerverwaltung im FRITZ!OS ansehen.
- verwaiste Links in der Übersicht korrigiert
- den JS-(Schönheits-)Fehler beim Ändern der FTP-Portnummer für den externen Zugriff findet bestimmt auch noch jemand
- der Mediaserver erlaubt ebenfalls noch den unbeschränkten Lese-Zugriff auf jede einzelne Datei, unabhängig vom Inhaltsverzeichnis und sonstigen NAS-Einstellungen ... ich habe die Hoffnung auch begraben, daß sich daran jemals etwas ändern wird
- - - Aktualisiert - - -
Die Thematik der "Vermischung" der Namensräume von DNS (fritz.box) und mDNS (local) hat AVM aber immer noch nicht angepackt:
Code:
hash 123:
wpad.fritz.box ([COLOR="#FF0000"]mdns[/COLOR]):
192.168.123.234 (dynamic)
fe80::201:2eff:feed:cafe (dynamic)
Code:
# dig @192.168.123.1 wpad.fritz.box. any
; <<>> DiG 9.9.6-P1 <<>> @192.168.123.1 wpad.fritz.box. any
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 11225
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 1, ADDITIONAL: 3
;; QUESTION SECTION:
;wpad.fritz.box. IN ANY
;; ANSWER SECTION:
[COLOR="#FF0000"]wpad.fritz.box. 9 IN A 192.168.123.234[/COLOR]
;; AUTHORITY SECTION:
wpad.fritz.box. 9 IN NS fritz.box.
;; ADDITIONAL SECTION:
fritz.box. 9 IN A 192.168.123.1
fritz.box. 9 IN AAAA fd00:c8a8:affe:0:a96:d7ff:feed:dead
fritz.box. 9 IN AAAA 2002:cafe:beef:0:a96:d7ff:feed:dead
;; Query time: 1 msec
;; SERVER: 192.168.123.1#53(192.168.123.1)
;; WHEN: Sun Nov 27 11:43:43 CET 2016
;; MSG SIZE rcvd: 134
