Hallo,
ich drehe mich wohl gerade im Kreise.
Ich habe hier eine einfache Tabelle (in einer Datenbank). Diese soll ist hinter einem QSqlTableModel. Das Model wird von einem QSqlTableView angezeigt.
Nun möchte ich gerne, daß immer (nicht nur bei leerer Tabelle) eine leere Zeile am Ende der Tabelle angezeigt wird um den Nutzer zu animieren, weitere Datensätze einzutragen.
Ich habe:
QSqlTableModel *m = …. m->insertRow(m->rowCount());
bin mir aber nicht sicher, ob das ins Model gehört. Außerdem wäre die Frage, wenn im Model ein weitere Zeile hinten dran muß. Jetzt habe ich es mit einem ProxyModel versucht, aber eigentlich - denke ich - wäre das doch etwas für den View, oder?
Hat schon mal jemand so etwas ähnliches gemacht? Oder sollte ich etwas genauer aufschreiben, was ich vorhabe?
Danke schon mal für's Mitdenken
Am Montag, 20. September 2010, 00:18:16 schrieb Heiko Schlittermann:
Ich habe:
QSqlTableModel *m = …. m->insertRow(m->rowCount());bin mir aber nicht sicher, ob das ins Model gehört.
Ich denke mal, das ist so richtig. Wenn der Datensatz dann hinzugefügt werden soll, gibt es m->submit().
Gruß Stefan
Hallo Ottmar!
Ich würde drei Tabellen anlegen:
Sorten: ID, Name, Beschreibung, Bild, Wikipedia-Artikel ... Krankheiten: ID, Name, Beschreibung, Bild ... Verbindung: Sorte_ID, Krankheit_ID, Haeufigkeit
Wenn du die Sorte mit JOIN zu den Krankheiten abfragst, bekommst du bei einem einzigen SELECT-Query alle Krankheiten direkt mitgeliefert.
welche Packages brauche ich ggf noch auser apache mysql und phpmyadmin
apache2, php5
SELFHTML ist ein schönes Grundlagenwerk, aber hoffnungslos veraltet. Ich würde zumindest die Formularvalidierung in jQuery schreiben.
Thomas
Am 20. September 2010 15:01 schrieb Thomas Schmidt schmidt@netaction.de:
SELFHTML ist ein schönes Grundlagenwerk, aber hoffnungslos veraltet. Ich würde zumindest die Formularvalidierung in jQuery schreiben.
Und bei abgeschaltetem JS oder manipulierten Skripten wird das Formular dann nicht validiert? Validierung gehört IMMER auf den Server, nicht auf den Client!
Viele Grüße Eric
Und bei abgeschaltetem JS oder manipulierten Skripten wird das Formular dann nicht validiert? Validierung gehört IMMER auf den Server, nicht auf den Client!
Sag das mal bitte Heiko Schlittermann, der soll eine Logikvalidierung im Mailserver installieren, falls die des Autors abgeschaltet oder manipuliert wurde.
Thomas
Am 22. September 2010 12:36 schrieb Thomas Schmidt schmidt@netaction.de:
Und bei abgeschaltetem JS oder manipulierten Skripten wird das Formular dann nicht validiert? Validierung gehört IMMER auf den Server, nicht auf den Client!
Sag das mal bitte Heiko Schlittermann, der soll eine Logikvalidierung im Mailserver installieren, falls die des Autors abgeschaltet oder manipuliert wurde.
Na dann erklär mal, wo der logische Fehler sein soll...
Viele Grüße Eric
Na dann erklär mal, wo der logische Fehler sein soll...
Es gibt verschiedene Fragen, die geklärt werden müssen. Ist zum Beispiel eine valide Eingabe für irgend jemand anders als den Benutzer schädlich? Wenn jemand bei der Anmeldung die doppelte Passworteingabe oder die Mailvalidierung aushebelt, schießt er sich nur selbst ins Knie.
Kommt es vor, dass JavaScript nicht korrekt ausgeführt wird? Dafür habe ich eine recht komplizierte Berechnung in jQuery auf eine Webseite gebaut und am Ende die URLs von bestimmten Links geändert. Ergebnis: Die Original-Links wurden zu etwa ein Promill angeklickt, bei allen anderen lief das jQuery.
Gibt es einen Grund, dass JS die serverseitige Validierung behindert? Das kann bei sehr komplizierten Formularen der Fall sein, denn dann muss man aufpassen, dass man die gesamte Logik fehlerfrei zweimal implementiert.
Ist es wahrscheinlich, dass ein Eingabefehler vorliegt? Wenn nicht, kann man den User ins Messer laufen lassen. Wenn doch, ist eine frühzeitige Warnung mit JS angebracht. Von daher muss man sich den speziellen Fall ansehen, in typischen Webapplikationen fördert eine JS-Validierung an manchen Stellen die Usability. Das Apfelprogramm klingt stark nach so einer Applikation.
Viele Grüße Thomas
On Wed, September 22, 2010 13:37, Thomas Schmidt wrote:
Ist es wahrscheinlich, dass ein Eingabefehler vorliegt? Wenn nicht, kann man den User ins Messer laufen lassen. Wenn doch, ist eine frühzeitige Warnung mit JS angebracht.
Viel Interessanter: kann eine absichtliche Fehleingabe vorliegen und kann diese schaedlich sein?
Von daher muss man sich den speziellen Fall ansehen, in typischen Webapplikationen fördert eine JS-Validierung an manchen Stellen die Usability.
Das ist es aber auch. JS ist pure Usability, es ist nicht Security und es funktioniert auch nicht immer.
Grundsaetze:
1) Eine Webapplikation muss auch funktionieren wenn $FEATURE abgeschaltet ist.
1a) $FEATURE = Javascript 1b) $FEATURE = Flash 1c) $FEATURE = $ALLESANDEREWASDIREINFAELLT
2) Eine Webapplikation darf kein Fehlverhalten zeigen wenn der Nutzer sie absichtlich manipuliert.
2a) Das gilt auch wenn der Nutzer/Angreifer bessere Tools als einen simplen Browser einsetzt.
2b) ...auch wenn der Angreifer mehr Ahnung hat als das Durchschnitts-Skript-Kid.
Konrad
Am 22. September 2010 13:37 schrieb Thomas Schmidt schmidt@netaction.de:
Es gibt verschiedene Fragen, die geklärt werden müssen. Ist zum Beispiel eine valide Eingabe für irgend jemand anders als den Benutzer schädlich? Wenn jemand bei der Anmeldung die doppelte Passworteingabe oder die Mailvalidierung aushebelt, schießt er sich nur selbst ins Knie.
Du kannst soviel clientseitige Validierung einbauen, wie Du willst. Das macht meine Aussage nicht ungültig oder unlogisch. Es ist nett von Dir, wenn Du den Benutzer darauf hinweisen willst, dass er vergessen hat seine EMail-Adresse einzutragen ohne, dass die ganze Seite neu geladen werden muß, aber trotzdem mußt Du sicherstellen, dass er im Namensfeld nicht etwa "Little Bobby Tables"[1] eingetragen hat. Machst Du das nur im Client, hast Du ein ernsthaftes Problem. Clientseitige Validierung dient der Benutzerfreundlichkeit, serverseitige der Sicherheit.
Viele Grüße Eric
Am 23. September 2010 07:49 schrieb Eric Schaefer eric@gixgax.de:
Machst Du das nur im Client, hast Du ein ernsthaftes Problem. Clientseitige Validierung dient der Benutzerfreundlichkeit, serverseitige der Sicherheit.
Wenn du mit Sicherheit den Schutz vor SQL-Injections und solchem Kram meinst, stimme ich dir zu. Das ist aber oft nur ein kleiner Teil der gesamten Validierung. Wenn du in der Usertable eines Forums den nick auf UNIQUE stehen hast und bei der Anmeldung einfach Nick, Passwort, E-Mail und Webseite ohne Überprüfung in die Tabelle kippst, kann dem Server und den anderen Usern nicht viel passieren, oder?
Dabei stimme ich dir allerdings nicht zu:
Validierung gehört IMMER auf den Server, nicht auf den Client!
Beispiel: Ich betreibe einen Webservice, bei dem man viele Patientendaten eingeben kann und dann die Wahrscheinlichkeit für das Auftreten einiger Krankheiten erhält. Die Berechnungsformel steckt in einem eigenen Programm mit eigener Validierung.
Der Weg sieht so aus: Die Eingaben werden mit jQuery clientseitig validiert. Der Server parst jedes Eingabefeld als Float und speichert die Daten. "3,5" wird dabei zu 3 und " 4" zu 0. Dann bezahlt der Kunde, die Daten gehen an die Berechnungsformel. Ich habe also die Validierung auf Plausibilität komplett aus dem Webserver geschmissen. Wenn in dieser ein Fehler auftritt, kann der Kunde weder korrigieren noch sein Geld zurückbekommen, er bekommt nur eine Fehlermeldung. Ergbebnis? Noch hat kein Kunde eine Fehlermeldung bekommen.
Viele Grüße Thomas
Am 23. September 2010 10:04 schrieb Thomas Schmidt schmidt@netaction.de:
Wenn du mit Sicherheit den Schutz vor SQL-Injections und solchem Kram meinst, stimme ich dir zu. Das ist aber oft nur ein kleiner Teil der gesamten Validierung. Wenn du in der Usertable eines Forums den nick auf UNIQUE stehen hast und bei der Anmeldung einfach Nick, Passwort, E-Mail und Webseite ohne Überprüfung in die Tabelle kippst, kann dem Server und den anderen Usern nicht viel passieren, oder?
Auch das ist eine serverseitige Validierung.
Beispiel: Ich betreibe einen Webservice, bei dem man viele Patientendaten eingeben kann und dann die Wahrscheinlichkeit für das Auftreten einiger Krankheiten erhält. Die Berechnungsformel steckt in einem eigenen Programm mit eigener Validierung.
Der Weg sieht so aus: Die Eingaben werden mit jQuery clientseitig validiert. Der Server parst jedes Eingabefeld als Float und speichert die Daten. "3,5" wird dabei zu 3 und " 4" zu 0. Dann bezahlt der Kunde, die Daten gehen an die Berechnungsformel. Ich habe also die Validierung auf Plausibilität komplett aus dem Webserver geschmissen. Wenn in dieser ein Fehler auftritt, kann der Kunde weder korrigieren noch sein Geld zurückbekommen, er bekommt nur eine Fehlermeldung. Ergbebnis? Noch hat kein Kunde eine Fehlermeldung bekommen.
Das ist keine Validierung im Client-Server-Sinne. Das ist einfach Anwendungslogik. Jetzt weiß ich auch, wo das Problem ist. Wenn man bei "Webkram" von Validierung spricht, meint man normalerweise die Überprüfung, ob die übermittelten Daten überhaupt gültige Werte darstellen. Letztlich prüfst Du damit ob die übergebenen Werte regulär verarbeitet werden können. Die Plausibilitätsprüfung ist eine ganz andere Ebene. Die Validierung, von der Du sprichst findet auf der "Anwendungsebene" statt, die die ich meine auf der Datenübertragungs-/speicherungs-Ebene. Bei "Deiner" Validierung geht es darum, das der Nutzer keinen Daten eingibt, die zu unsinnigen Ergebnissen führen würden. "Meine" Validierung prüft, dass der Nutzer keine Daten "eingibt", die z.B. zu kompromittierten Daten führen könnten.
Viele Grüße Eric
Am 23. September 2010 14:42 schrieb Eric Schaefer eric@gixgax.de:
Wenn man bei "Webkram" von Validierung spricht, meint man normalerweise die Überprüfung, ob die übermittelten Daten überhaupt gültige Werte darstellen. Letztlich prüfst Du damit ob die übergebenen Werte regulär verarbeitet werden können. Die Plausibilitätsprüfung ist eine ganz andere Ebene.
Ja OK, diese "Webkram"-Validierung muss auf dem Server geschehen. Man braucht sie wohl nur selten zwecks Usability auch in den Client zu bauen. Aber ich denke, sie wird immer seltener gebraucht. Wenn du die Datenbank über PHP Data Objects ansprichst, ist die Sache mit den SQL-Injections abgehakt. Wenn ein Forum <>&" bei der Anzeige escaped, sind Cross-Site-Scripts (XSS-Angriff) ausgeschlossen.
Viele Grüße Thomas
Hallo Eric, Hallo Thomas, Hallo Liste,
Vor der "Entdeckung" von AJAX für viele Frameworks und ebenso für viele Entwickler, war die erste Validierungsstufe auf der Clientseite angesiedelt und dort auch ganz gut aufgehoben, wenn der Server zusätzliche Kontrollen durchgeführt hat. Der Vorteil war einfach, dass ein Formular nicht erst abgeschickt werden musste.
Mittlerweile finden viele Validierungen mehrfach auf dem Server statt. Wenn der User JavaScript zulässt und alles erfolgreich klappt, kann per AJAX direkt bei der Eingabe ein Hinweis an den Besucher geleitet werden. Zusätzlich findet anschließend noch eine serverseitige Kontrolle statt.
Es besteht kein Grund, solch hitzige Diskussionen zu führen, denn eigene Meinungen sind gewünscht und finden Beachtung, sofern man sich damit anfreundet, dass es andersdenkende Menschen gibt.
Liebe Grüße und einen sonnigen Restnachmittag
Björn
On 22.09.2010 13:15, Eric Schaefer wrote:
Am 22. September 2010 12:36 schrieb Thomas Schmidt schmidt@netaction.de:
Und bei abgeschaltetem JS oder manipulierten Skripten wird das Formular dann nicht validiert? Validierung gehört IMMER auf den Server, nicht auf den Client!
Sag das mal bitte Heiko Schlittermann, der soll eine Logikvalidierung im Mailserver installieren, falls die des Autors abgeschaltet oder manipuliert wurde.
Na dann erklär mal, wo der logische Fehler sein soll...
Viele Grüße Eric
Hallo
Hallo Eric, Hallo Thomas, Hallo Liste,
Vor der "Entdeckung" von AJAX für viele Frameworks und ebenso für viele Entwickler, war die erste Validierungsstufe auf der Clientseite angesiedelt und dort auch ganz gut aufgehoben, wenn der Server zusätzliche Kontrollen durchgeführt hat. Der Vorteil war einfach, dass ein Formular nicht erst abgeschickt werden musste.
Ich finde mehrfache Validierung nicht schlecht, doch sollte wenigstens eine sein und da kann man sich nur sicher sein das die auf dem server gemacht wird denn die andere validierung kann ich überlisten, und man vertraut doch keinen daten die man nicht kennt
Mittlerweile finden viele Validierungen mehrfach auf dem Server statt. Wenn der User JavaScript zulässt und alles erfolgreich klappt, kann per AJAX direkt bei der Eingabe ein Hinweis an den Besucher geleitet werden. Zusätzlich findet anschließend noch eine serverseitige Kontrolle statt.
Es besteht kein Grund, solch hitzige Diskussionen zu führen,
ich finde die Diskussionen dürfen heftig sein, nur darf man sich nicht beleidigen was hier meines erachten nicht passierte(auch wenn ansätze dafür zu erkennen sind)
denn eigene Meinungen sind gewünscht und finden Beachtung, sofern man sich damit anfreundet, dass es andersdenkende Menschen gibt.
Natürlich sind andere Meinungen gewünscht
und man sollte auch auf gefahren hinweisen, wichtige ist nur das man andere meinungen auch einfach respektiert auch wenn sie einen falsch vokommen
andreas
Liebe Grüße und einen sonnigen Restnachmittag
Björn
On 22.09.2010 13:15, Eric Schaefer wrote:
Am 22. September 2010 12:36 schrieb Thomas Schmidt schmidt@netaction.de:
Und bei abgeschaltetem JS oder manipulierten Skripten wird das Formular dann nicht validiert? Validierung gehört IMMER auf den Server, nicht auf den Client!
Sag das mal bitte Heiko Schlittermann, der soll eine Logikvalidierung im Mailserver installieren, falls die des Autors abgeschaltet oder manipuliert wurde.
Na dann erklär mal, wo der logische Fehler sein soll...
Viele Grüße Eric
On Wed, September 22, 2010 12:36, Thomas Schmidt wrote:
Und bei abgeschaltetem JS oder manipulierten Skripten wird das Formular dann nicht validiert? Validierung gehört IMMER auf den Server, nicht auf den Client!
Sag das mal bitte Heiko Schlittermann, der soll eine Logikvalidierung im Mailserver installieren, falls die des Autors abgeschaltet oder manipuliert wurde.
Worueber redest Du bitte? Welche Logikvalidierung soll in Heikos Mailserver bitte fehlen?
Dass Mails mit so konfusen Saetzen durchkommen ist nicht das Problem des Servers. Der Server validiert durchaus dass nicht allzu grosser Unfug passiert.
Konrad
Thomas Schmidt schmidt@netaction.de (Mi 22 Sep 2010 12:36:56 CEST):
Und bei abgeschaltetem JS oder manipulierten Skripten wird das Formular dann nicht validiert? Validierung gehört IMMER auf den Server, nicht auf den Client!
Sag das mal bitte Heiko Schlittermann, der soll eine Logikvalidierung im Mailserver installieren, falls die des Autors abgeschaltet oder manipuliert wurde.
Irgendwie steh' ich hier neben der Mütze.
Stefan Majewsky majewsky@gmx.net (Mo 20 Sep 2010 08:24:10 CEST):
Am Montag, 20. September 2010, 00:18:16 schrieb Heiko Schlittermann:
Ich habe:
QSqlTableModel *m = …. m->insertRow(m->rowCount());bin mir aber nicht sicher, ob das ins Model gehört.
Ich denke mal, das ist so richtig. Wenn der Datensatz dann hinzugefügt werden soll, gibt es m->submit().
Hm. Irgendwie macht die Library komische Dinge. Ich versuche mal, ein einfaches Beispiel zu bauen und das ganze zu reproduzieren. Aber eigentlich glaube ich immer noch nicht, daß das ins Modell gehört. Das könnte ja auch von anderen Views genutzt werden, und die wollen vielleicht die leere Zeile gar nicht sehen.
Komisch, daß im QSqlTableView diese o. erwähnte neue Zeile keine Zeilennummer erhält, sondern einen „*“. Also scheint jemand zu wissen, daß das kein realer Datensatz ist. Und die andere Beobachtung, daß man nicht mehrere leere Zeilen inserten kann. Es zumindest der rowCount scheint sich dann nicht zu ändern.
Aber alles Beobachtungen, keine Dokumentation.
Schade, daß dieser Thread jetzt mit Äpfeln kaputt ist.
lug-dd@mailman.schlittermann.de
-
Björn Abheiden -
Eric Schaefer -
Grimnin Fridyson -
Heiko Schlittermann -
Konrad Rosenbaum -
Ottmar-Schmidt＠web.de -
Stefan Majewsky -
Thomas Schmidt