nicht angemeldet
TS
TS
TS
robertroth
Auge
Auge
Hab' Formulare zur Eingabe mehrerer Schlüssel-Werte-Paare, z.B. für bestimmte Shop-Konfigurationen.
Untendran ein Button "Daten Speichern". Beim Klick da drauf dreht sich ne Sanduhr, die Seite wird etwas durchsichtiger (per opacity) und wenn alle Daten am Server sind (per ajax).... tja, was machen bzw. zeigen wir da?
Meinungen, Alternativen, Ideen?
Danke und vile Grüse, Dag
Hallo und guten Abend,
Hab' Formulare zur Eingabe mehrerer Schlüssel-Werte-Paare, z.B. für bestimmte Shop-Konfigurationen.
Untendran ein Button "Daten Speichern". Beim Klick da drauf dreht sich ne Sanduhr, die Seite wird etwas durchsichtiger (per opacity) und wenn alle Daten am Server sind (per ajax).... tja, was machen bzw. zeigen wir da?
Erste Rückfrage: was hat hier Ajax zu suchen?
Deine Fragen:
- 1) ein Popup like "Konfiguration gespeichert" aufblitzen lassen,
- 2) nix Popup, das Erscheinen und Verschwinden der Sanduhr sollte genügen,
- 3) kein Popup, aber an einer bestimmten Stelle an der Seite den Hinweis zeigen, dass
'Daten erfolgreich gespeichert' wurden,
- 3a) dieser Hinweis blinkt,
- 3b) dieser Hinweis blinkt n mal und verschwindet dann spontan,
- ...
- 99) auf jeden Fall was gut Sichtbares, wenns Speichern in die Hose gegangen ist.
Spannend wärew die Frage des Response-Status-Codes.
Und außerdem ist es meistens sinnvoll, die Ergebnisse eines POST als flüchtige GET-Response wieder abzuholen und anzuzeigen, also:
Grüße
TS
hi,
Spannend wärew die Frage des Response-Status-Codes.
Och nö, obern Status-Code wird das bei mir nicht geregelt, wenn beim Speichern was schiefgegangen ist. Für solche Fehler gibts in der response ein Datenfeld 'errstr' und wenn da was drinsteht, kommt ein alert(errstr) und fertig.
Und außerdem ist es meistens sinnvoll, die Ergebnisse eines POST als flüchtige GET-Response wieder abzuholen und anzuzeigen, also:
- anfordern (lesen)
- lesen und beantworten
- schreiben . nochmal lesen lassen
Machs nicht so kompliziert. OnClick: Formularfelder lesen, ab zum Server, fertig. Oder ab in eine lokale Datei (optional).
In meiner Anwendung lade ich 'zig Konfigs at once (GET auf z.B. /shopconfig.html), die sind zunächst display:none; nach Auswahl aus der datalist wird das Formular für die gewählte Config auf display:block gesetzt, da gehts rein in die Datenfelder, Klick auf Speichern und fertig. Das sind ganze 90 Zeilen Perl, und 30 Zeilen Javascript (Libs und Templates außen vor).
Anwendungsseite einmal laden + Konfigs/Formulare anfordern => ein Request. Speichern je Formular => ein optionaler Request. Total übersichtlich und nicht 'zig mal hin und her.
Vile Grüse, Dag ;)
Hallo und guten Morgen,
Spannend wärew die Frage des Response-Status-Codes.
Och nö, obern Status-Code wird das bei mir nicht geregelt, wenn beim Speichern was schiefgegangen ist. Für solche Fehler gibts in der response ein Datenfeld 'errstr' und wenn da was drinsteht, kommt ein alert(errstr) und fertig.
Und wie verhält sich dein Dokument dann, wenn man auf reload klickt?
Grüße
TS
Hallo und guten Morgen,
Spannend wärew die Frage des Response-Status-Codes.
Och nö, obern Status-Code wird das bei mir nicht geregelt, wenn beim Speichern was schiefgegangen ist. Für solche Fehler gibts in der response ein Datenfeld 'errstr' und wenn da was drinsteht, kommt ein alert(errstr) und fertig.
Und wie verhält sich dein Dokument dann, wenn man auf reload klickt?
ganz unkompliziert ;)
Also, es werden alle für den URL konfigur1erten n Config's einschließlich deren Formulardefinitionen (Felder für Attr => Value) neu geladen und alle Formulare (Index 1..n) unsichtbar gemacht.
Sichtbar bleibt Formular mit index 0, hier wählt der Benutzer die gewünschte Config aus; Beispiel 'shopconfig','basic' und damit wird dann das Formular für 'basic' sichtbar gemacht (Daten stehen, soweit serverseitig vorhanden, schon drin).
Weitere Features: Config-Datei download/upload, z.B. zum lokalen Sichern/Zurückspielen aller Konfigurationen.
Die auf der Config stehende Anwendung gibt Fehler aus, wenn bestimmte Attribute nicht konfiguriert sind.
--Dag
Mahlzeit,
Spannend wärew die Frage des Response-Status-Codes.
Und wie verhält sich dein Dokument dann, wenn man auf reload klickt?
Genauso wie ein gewöhnlicher Editor als Desktopanwendung: Datenfluss von Datei zum Editor. Beim Speichern ist es umgekehrt: Datenfluss von Editor zur Datei.
Und weil meine Anwendung genauso tut, werde ich neben dem Speichern-Button ein * anzeigen, sofern Daten im Browser geändert wurden. Klick auf den Speicherbutton: kurze Sanduh, Sanduhr und * verschwinden wieder, wenn die Daten gespeichert sind.
Ich muss jetzt nur mal gucken, ob es in JS eine Möglichkeit gibt, MD5-Checksummen zu berechnen. Dankbar für diesbez. Tipps,
Dag
Tach,
Ich muss jetzt nur mal gucken, ob es in JS eine Möglichkeit gibt, MD5-Checksummen zu berechnen.
natürlich, bitte nicht selber implementieren, das geht bei Crypto-Algorithmen fast immer schief (auch wenn dein aktueller Anwendungsfall vielleicht keine Crypto-Anwendung ist); besser noch, nimm gleich einen besseren Algorithmus (z.B. SHA-2), sonst werden wir MD5 ja nie los.
mfg
Woodfighter
Tach,
Ich muss jetzt nur mal gucken, ob es in JS eine Möglichkeit gibt, MD5-Checksummen zu berechnen.
natürlich, bitte nicht selber implementieren, das geht bei Crypto-Algorithmen fast immer schief (auch wenn dein aktueller Anwendungsfall vielleicht keine Crypto-Anwendung ist); besser noch, nimm gleich einen besseren Algorithmus (z.B. SHA-2), sonst werden wir MD5 ja nie los.
Tja. Heutzutage gips eben einfach alles schon fix und fertig vorprogrammiert und das auch noch meistens for umsonst.
Danke fürn Link, Dag ;)
Hallo und guten Tag,
Tja. Heutzutage gips eben einfach alles schon fix und fertig vorprogrammiert und das auch noch meistens for umsonst.
und man weiß nicht immer, was eignetlich drinsteckt in dem "umsonst"-Paket
Grüße
TS
Tach,
Tja. Heutzutage gips eben einfach alles schon fix und fertig vorprogrammiert und das auch noch meistens for umsonst.
und man weiß nicht immer, was eignetlich drinsteckt in dem "umsonst"-Paket
das ist allerdings bei Crypto relativ einfach; ist es nicht Open Source, ist es keine Crypto; und dann kann man es sich selber angucken, oder eher, weil Crypto lesen nicht viel einfacher als Crypto schreiben ist, sich auf andere verlassen, die sich das angeguckt haben.
mfg
Woodfighter
Liebe Mitdenker, liebe Wissende, liebe Neugierige,
Tja. Heutzutage gips eben einfach alles schon fix und fertig vorprogrammiert und das auch noch meistens for umsonst.
und man weiß nicht immer, was eignetlich drinsteckt in dem "umsonst"-Paket
das ist allerdings bei Crypto relativ einfach; ist es nicht Open Source, ist es keine Crypto; und dann kann man es sich selber angucken, oder eher, weil Crypto lesen nicht viel einfacher als Crypto schreiben ist, sich auf andere verlassen, die sich das angeguckt haben.
Klar! Hat ja bei OpenSSH auch prima geklappt. :-D
Spirituelle Grüße
Euer Robert
robert.r@online.de
Tach,
das ist allerdings bei Crypto relativ einfach; ist es nicht Open Source, ist es keine Crypto; und dann kann man es sich selber angucken, oder eher, weil Crypto lesen nicht viel einfacher als Crypto schreiben ist, sich auf andere verlassen, die sich das angeguckt haben.
Klar! Hat ja bei OpenSSH auch prima geklappt. :-D
ich vermute du meinst OpenSSL? Natürlich ist es Müll, etwas wie den Heartbleed-Bug auszuliefern, aber auch der ist gefunden und gefixt worden, weil es Open Source war.
mfg
Woodfighter
Liebe Mitdenker, liebe Wissende, liebe Neugierige,
Tach,
das ist allerdings bei Crypto relativ einfach; ist es nicht Open Source, ist es keine Crypto; und dann kann man es sich selber angucken, oder eher, weil Crypto lesen nicht viel einfacher als Crypto schreiben ist, sich auf andere verlassen, die sich das angeguckt haben.
Klar! Hat ja bei OpenSSH auch prima geklappt. :-D
ich vermute du meinst OpenSSL?
SSH -> SSL: das war auch ein Bug in meinem Gedächtnis. Aber nicht gut genug. Du hast ihn gleich gesehen.
Natürlich ist es Müll, etwas wie den Heartbleed-Bug auszuliefern, aber auch der ist gefunden und gefixt worden, weil es Open Source war.
Das liegt a dem Tick der C/C++ Programmierer, immer alles so zu schreiben, dass Andere es möglichst nicht mehr lesen können. Was sind das doch für tolle Kerle.
Wenn man solche Dinge in Modula2 oder ähnlichen Sprachen schreiben würde unter Ausnutzung der Range-Checks, würde ich glauben, dass derartige Fehler ausbleiben würden.
Spirituelle Grüße
Euer Robert
robert.r@online.de
Tach,
Natürlich ist es Müll, etwas wie den Heartbleed-Bug auszuliefern, aber auch der ist gefunden und gefixt worden, weil es Open Source war.
Das liegt a dem Tick der C/C++ Programmierer, immer alles so zu schreiben, dass Andere es möglichst nicht mehr lesen können. Was sind das doch für tolle Kerle.
die Kritik kann ich in diesem Zusammenhang nicht verstehen; der Heartbleed-Fix zeigt, dass das Problem im Prinzip ein relativ simples war und der Code ist nicht übermäßig unverständlich.
Wenn man solche Dinge in Modula2 oder ähnlichen Sprachen schreiben würde unter Ausnutzung der Range-Checks, würde ich glauben, dass derartige Fehler ausbleiben würden.
Hätte der nötige Range-Check stattgefunden, hätte es den Bug auch in C nicht gegeben und klar, mit einer Sprache, die memory safe ist, ebenfalls nicht; allerdings sind Prgramme wie OpenSSl ja nicht in C geschrieben, weil es self-obfuscating ist, sondern weil es zum Zeitpunkt des Starts des Projekt nicht viel Auswahl an performanten, portablen Sprachen gab. (siehe z.B. http://www.dwheeler.com/essays/heartbleed.html#safe-language); und OpenSSL mal eben in einer anderen Sprache neu umsetzen, würde voraussetzen, dass du Experten findest, die erstens diese andere Sprache ausreichend gut beherrschen und die zum Teil abwegigen Side Channel kennen müssen, die beim implementieren von TLS anfallen. Ich hoffe, dass wir in Zukunft für alle kritische Software Sprachen nutzen werden, die ESC und/oder ähnliches umsetzen; aber das wird dauern.
OpenSSL ist sicher kein Vorzeigeprodukt, wo alles so ist, wie man sich das wünschen würde; aber trotzdem vertraue ich dem deutlich mehr, als einer Implementierung in die niemand reinschauen kann.
mfg
Woodfighter
Hallo
Ich muss jetzt nur mal gucken, ob es in JS eine Möglichkeit gibt, MD5-Checksummen zu berechnen. Dankbar für diesbez. Tipps,
Neben der von woodfigther genannten Implementation gibt es viele andere, wie z.B. die hier. Er hat aber auch mit seiner Kritik recht. Auch wenn ich vermute, dass du Prüfsummen über die Dokumente erstellen willst und nicht „Passwörter“, sind andere Verfahren als MD5 besser (wegen der möglichen Kollisionen).
Tschö, Auge
Tach,
Er hat aber auch mit seiner Kritik recht. Auch wenn ich vermute, dass du Prüfsummen über die Dokumente erstellen willst und nicht „Passwörter“, sind andere Verfahren als MD5 besser (wegen der möglichen Kollisionen).
er ist auch der Meinung, dass man MD5 auch nicht für Passwörter verwenden sollte. Zum ersten ist es dafür einfach zu schnell und zum zweiten ist es für manche Anwendungen gebrochen, nie MD5 nutzen ist also fehlerfreier als jedesmal darüber nachdenken zu müssen.
mfg
Woodfighter
Hallo
Tach,
Er hat aber auch mit seiner Kritik recht. Auch wenn ich vermute, dass du Prüfsummen über die Dokumente erstellen willst und nicht „Passwörter“, sind andere Verfahren als MD5 besser (wegen der möglichen Kollisionen).
er ist auch der Meinung, dass man MD5 auch nicht für Passwörter verwenden sollte. …
Das hab' ich auch nicht angezweifelt oder gar propagieren wollen, MD5 für Passwörter zu verwenden.
Tschö, Auge
Tach,
Er hat aber auch mit seiner Kritik recht. Auch wenn ich vermute, dass du Prüfsummen über die Dokumente erstellen willst und nicht „Passwörter“, sind andere Verfahren als MD5 besser (wegen der möglichen Kollisionen).
er ist auch der Meinung, dass man MD5 auch nicht für Passwörter verwenden sollte. …
Das hab' ich auch nicht angezweifelt oder gar propagieren wollen, MD5 für Passwörter zu verwenden.
ah ja, jetzt habe ich den Satz auch so verstanden, wie du ihn meintest.
mfg
Woodfighter
hallo,
er ist auch der Meinung, dass man MD5 auch nicht für Passwörter verwenden sollte. Zum ersten ist es dafür einfach zu schnell und zum zweiten ist es für manche Anwendungen gebrochen, nie MD5 nutzen ist also fehlerfreier als jedesmal darüber nachdenken zu müssen.
Nutze das Asterisk-Encrypting:
pass=********
;) Dag
Mahlzeit,
Hab' Formulare zur Eingabe mehrerer Schlüssel-Werte-Paare, z.B. für bestimmte Shop-Konfigurationen.
Untendran ein Button "Daten Speichern". Beim Klick da drauf dreht sich ne Sanduhr, die Seite wird etwas durchsichtiger (per opacity) und wenn alle Daten am Server sind (per ajax).... tja, was machen bzw. zeigen wir da?
Erste Rückfrage: was hat hier Ajax zu suchen?
Machs einfach mal, ist in einer Stunde programmiert, oder spiel das mal gedanklich durch:
Dass hierbei HTTP im Spiel ist, ist dem Anwender transparent, er kriegt das gar nicht mit, weil beim Speichern die Seite nicht neu geladen wird.
Und dann vergleiche das mal mit einer auf herkömmliche Art programmierten Anwendung, wo beim Speichern ein Submit erfolgt und danach die Seite neu geladen wird.
Insbesondere, wenn es mehrere Configs sind. Oder überhaupt Backend's fürs Content-Management.. also ich meine, mit ajax gewinnt das alles erheblich an Benutzerfreundlichkeit und ist letztendlich auch viel einfacher zu programmieren.
Dag
Hallo und guten Nachmittag,
Hab' Formulare zur Eingabe mehrerer Schlüssel-Werte-Paare, z.B. für bestimmte Shop-Konfigurationen.
Untendran ein Button "Daten Speichern". Beim Klick da drauf dreht sich ne Sanduhr, die Seite wird etwas durchsichtiger (per opacity) und wenn alle Daten am Server sind (per ajax).... tja, was machen bzw. zeigen wir da?
Erste Rückfrage: was hat hier Ajax zu suchen?
Machs einfach mal, ist in einer Stunde programmiert, oder spiel das mal gedanklich durch:
- Aufzählungs-Text
- Formular ausgefüllt mit Daten in den Browser laden
- zum Speichern die Daten mit ajax übertragen
Dass hierbei HTTP im Spiel ist, ist dem Anwender transparent, er kriegt das gar nicht mit, weil beim Speichern die Seite nicht neu geladen wird.
Und dann vergleiche das mal mit einer auf herkömmliche Art programmierten Anwendung, wo beim Speichern ein Submit erfolgt und danach die Seite neu geladen wird.
Insbesondere, wenn es mehrere Configs sind. Oder überhaupt Backend's fürs Content-Management.. also ich meine, mit ajax gewinnt das alles erheblich an Benutzerfreundlichkeit und ist letztendlich auch viel einfacher zu programmieren.
Jein. Hab ich auch schon gemacht. Hab aber jedes Mal Probleme mit der Fallback-Lösung bekommen. Entweder zu Fuß programmieren (puh totaler Aufwand), dann hat sie funktioniert, oder "Fertiglösungen" benutzen, dann hat immer 'was geklemmt.
Und wenn es nur das Reload oder History-Back im Browser war.
Grüße
TS
Hallo ;
Jein. Hab ich auch schon gemacht. Hab aber jedes Mal Probleme mit der Fallback-Lösung bekommen.
Ja, wenn ganz plötzlich und unerwartet Javascript im Browser ausfällt, da kannste eigentlich gar nüscht mache...
;) Dag
Hallo Dag,
- ein Popup like "Konfiguration gespeichert" aufblitzen lassen,
This.
Kein User-Feedback ist nicht sinnvoll, dann wird sich der User immer fragen ob die Operation geklappt hat oder nicht. Ein Hinweis an einer bestimmten Stelle ist ungünstig, weil der User sich an einer anderen Stelle im Dokument befinden kann und der Hinweis dann nicht im Viewport ist.
- auf jeden Fall was gut Sichtbares, wenns Speichern in die Hose gegangen ist.
Das auch auf jeden Fall, ja.
LG,
CK
hi CK,
- ein Popup like "Konfiguration gespeichert" aufblitzen lassen,
This.
Ja, genau das hab ich hier ja auch gesehen, sieht gut aus ;)
Vile Grüse, Dag ;)