Datenvalidierung mit Transaktion - Wie am besten Ablauf verketten? (Allgemeines zu Perl)

[thread]13588[/thread]

Datenvalidierung mit Transaktion - Wie am besten Ablauf verketten?

Leser: 18

Articles: hide open all | hide show old branches

+11 replies
sid burn

2009-05-29 14:17
User since
2006-03-29
1520 Artikel
BenutzerIn
Hi,
sry für die vielleicht etwas Dumme überschrift aber etwas besseres ist mir nicht eingefallen, aber es kommt schon so ähnlich in die Richtigung was ich machen möchte.

Ich habe mir vorgenommen ein CPAN Modul zu schreiben das Daten Validiert, hauptsächlich deswegen weil ich mit keiner Lösung die auf dem CPAN bereits existiert zu frieden bin. Ich habe mir Gestern dazu einige Konzepte überlegt. Primär soll die komplette Validierung Exception basiert sein. Daher fällt ein Check fehl wirft es Exception Objekte die dann später noch genauer Untersucht werden können. Das ganze wäre nicht weiter schwierig, allerdiengs möchte man ja auch öfters mal mehrere Checks hintereinander ausführen und zum schluß eine Zusammenfassung aller Fehler bekommen. Im Sinne von Exceptions wäre es aber Toll wenn trotzdem noch automatisiert bei einem fehler eben eine exception geworfen wird ohne zutun. Genau hier liegt mein Problem da ich nicht weiß ob soetwas überhaupt machbar wäre.

Nehmen wir folgenden Pseudo-Code an:
Code (perl): (dl )

1 2 3 4 5

$validate ->check(...) ->check(...) ->check(...) ->check(...);
Es wäre also Toll wenn alle checks ersteinmal durchlaufen und dann ganz zum schluß erst eine Exception geworfen wird wenn irgendeine Validierung fehlgeschlagen ist. Dafür müsste ich allerdiengs Wissen das hinter einem check() Aufruf ein weiterer kommt, und ich müste wissen ob ein check aufruf der letzte aufruf in der kette ist. Ist soetwas möglich?

Zum mitteilen das nun eine reihe von checks folgen könnte man ja eine zusätzliche routine setzen, also soetwas.
Code (perl): (dl )

1 2 3 4

$validate ->assemble() ->check(...) ->check(...);
So das er durch die assemble() funktion weiß das jetzt eine reihe von checks kommen, das wäre denke ich noch okay. Eine erweiterung das man es noch abschließen muss und dieses dann eine exception wirft oder nicht wäre natürlich die simpelste lösung.
Code (perl): (dl )

1 2 3 4 5

$validate ->assemble() ->check(...) ->check(...) ->result();
Allerdiengs hat man hier den nachteil das man das result() vergessen kann, und damit würde das ganze Exception Handling auser Kraft gesetzt werden.

Ich hatte mir schon eine andere Möglichkeit überlegt einen neuen Kontext zu erstellen.
Code (perl): (dl )

1 2 3 4 5 6

eval { my $context = $validate->assemble(); $validate ->check(...) ->check(...); };
So das wenn $context aus dem Scope läuft DESTROY() aufgerufen wird, dieser das Checking vornimmt, und dann DESTROY eine Exception wirft oder nicht. Daher auch dieser Thread hier: http://www.perl-community.de/bat/poard/thread/1358...

Aber anscheind geht dieser Weg auch nicht. Irgendjemand eine Idee ob das Möglich ist was ich mir vorstelle?

Wenn absolut gar nichts mehr geht werden ich wohl auf eine anonyme Subroutine zurück greifen, also soewtas in der art.
Code (perl): (dl )

1 2 3 4 5 6

$validate->assemble(sub{ $validate ->check(...) ->check(...) ->check(...); });
Allerdiengs bin ich darüber nicht ganz so Glücklich. Irgendjemand noch andere gut Ideen oder Einfälle?
Nicht mehr aktiv. Bei Kontakt: ICQ: 404181669 E-Mail: perl@david-raab.de
- +7 replies
- GwenDragon
  
  2009-05-29 14:32
  
  User since
  2005-01-17
  14745 Artikel
  Admin1
  
  Ich habe mal den Titel etwas verständlicher angelegt. Ist doch so gemeint, oder?
  
  Das ganze in ein eval zu verpacken ist ja auch in anderen Sprachen wie mit try/catch üblich.
  
  Du kannst natürlich alle Funktionen hintereinander ablaufen lassen, ein Flag mitführen, bei jeder fehlgeschlagenen Aktion hochzählen. Wenn dieses Flag immer auf 0 ist, dann kannst du die Transaktion starten, ansonsten alles rückgängig machen.
  Last edited: 2009-05-29 14:36:27 +0200 (CEST)
  die Drachin Gwen
  
  Meine Perl-Artikel · perldev – verschiedene Perl-Versionen unter Windows starten
  - sid burn
    
    2009-05-29 14:35
    
    User since
    2006-03-29
    1520 Artikel
    BenutzerIn
    
    2009-05-29T12:32:53 GwenDragon
    Ich habe mal den Titel etwas verständlicher angelegt. ISst doch so gemeint, oder?
    
    Ja, danke.
    Wollte den Titel nach dem erstellen auch nochmal ändern, ist ja leider nicht Möglich.
    Nicht mehr aktiv. Bei Kontakt: ICQ: 404181669 E-Mail: perl@david-raab.de
  - +5 replies
  - sid burn
    
    2009-05-29 15:00
    User since
    2006-03-29
    1520 Artikel
    BenutzerIn
    
    2009-05-29T12:32:53 GwenDragon
    Das ganze in ein eval zu verpacken ist ja auch in anderen Sprachen wie mit try/catch üblich.
    
    Ja das soll man später ja auch machen.
    
    Code (perl): (dl )
    
    1 2 3 4 5 6 7 8 9 10 11 12 13
    
    eval { $validate ->assemble() ->check(...) ->check(...) ->check(...); # Code wenn alle Checks okay waren. }; if ( $@ ) { # Fehler aufgetreten # Liste der Exceptions durchgehen und schauen welche Felder fehelrhaft waren }
    
    Nur muss der letzte check ja eine Exception werfen. durch das assemble() kann man ja letztendlich umschalten das man Fehler erstmal abfängt. Aber der letzte check muss ja eine exception werfen die den eval Block beendet.
    
    Werfe ich einfach bei allen eine exception (default) dann wäre ich aber nicht in der lage eine komplette liste zu erhalten welche felder alles invalide sind, sondern ich würde immer nur das erste feld zurück bekommen.
    
    Quote
    Du kannst natürlich alle Funktionen hintereinander ablaufen lassen, ein Flag mitführen, bei jeder fehlgeschlagenen Aktion hochzählen. Wenn dieses Flag immer auf 0 ist, dann kannst du die Transaktion starten, ansonsten alles rückgängig machen.
    
    Das mit dem Flag mitführen hatte ich mir so auch schon so ähnlich gedacht, nur das eben alle Exceptions die geworfen wurden erstmal gesammelt werden. Der letzte Check muss dann allerdiengs nicht nur sammeln sondern muss dann eine echte Exception werfen, damit der eval Block beendet wird.
    
    Okay eine echte Transaktion ist es nicht weil nichts mehr Rückgängig gemacht wird (daher sagte ich ja das der titel nicht so ganz passt, wenn dir eine bessere beschreibung einfällt dann ändere den titel einfach nochmal)
    Last edited: 2009-05-29 15:06:52 +0200 (CEST)
    Nicht mehr aktiv. Bei Kontakt: ICQ: 404181669 E-Mail: perl@david-raab.de
    - +2 replies
    - GwenDragon
      
      2009-05-29 15:28
      
      User since
      2005-01-17
      14745 Artikel
      Admin1
      
      [quote="sid burn@2009-05-29T13:00:09"]
      2009-05-29T12:32:53 GwenDragon
      Der letzte Check muss dann allerdiengs nicht nur sammeln sondern muss dann eine echte Exception werfen, damit der eval Block beendet wird.
      
      Hmm, wegen des Handlings würde ich sozusagen alle Checks in eine Liste (Stack) schieben und dem letzten Eintrag in der Liste die Exceptionroutine zuweisen und dann den Stack nacheinander abarbeiten. Aber vielleicht ist das ein Dinosaurierrelikt, ein veraltetes Denken aus meinen Zeiten als Programmiererin für embedded systems.
      
      Hast du ein eigenes Exception-Handlung? Kannst ja mal auch auf CPAN nach exception suchen.
      
      Mir fällt gerade nix als Code ein.
      die Drachin Gwen
      
      Meine Perl-Artikel · perldev – verschiedene Perl-Versionen unter Windows starten
      - sid burn
        
        2009-05-29 15:43
        
        User since
        2006-03-29
        1520 Artikel
        BenutzerIn
        
        Quote
        Hmm, wegen des Handlings würde ich sozusagen alle Checks in eine Liste (Stack) schieben und dem letzten Eintrag in der Liste die Exceptionroutine zuweisen und dann den Stack nacheinander abarbeiten. Aber vielleicht ist das ein Dinosaurierrelikt, ein veraltetes Denken aus meinen Zeiten als Programmiererin für embedded systems.
        
        Genau an sowas habe ich auch schon gedacht, nur woher erkenne ich die letzte routine so das ich das abarbeiten der liste starten lassen kann?
        
        Wenn ich am ende eine Routine wie result() mache die das abarbeiten startet dann lande ich eben da das man das result() vergessen kann, und dann hat man auf einmal gar keine validierung mehr.
        
        Quote
        Hast du ein eigenes Exception-Handlung? Kannst ja mal auch auf CPAN nach exception suchen.
        
        Du meinst ein Modul das mir Exceptions vereinfacht? Für den Aufbau der Exceptions werde ich wohl Exception::Class nutzen.
        
        Oder ich muss das interface komplett umbauen
        
        Code (perl): (dl )
        
        1 2 3 4 5 6
        
        $validate->check([ { 'check', { ..options.. } }, { 'check', { ..options.. } }, { 'check', { ..options.. } }, { 'check', { ..options.. } }, ]);
        
        Finde ich aber nicht mehr so schön.
        Last edited: 2009-05-29 15:45:03 +0200 (CEST)
        Nicht mehr aktiv. Bei Kontakt: ICQ: 404181669 E-Mail: perl@david-raab.de
    - +2 replies
    - Gast MatthiasW
      
      2009-05-29 15:58
      
      Du könntest auch eine Methode(zB lcheck) hernehmen und mit Arrayreferenzen füttern. lcheck() führt dann für jede der Arrayreferenzen ein check() aus und fängt die Exceptions ab. Nachdem alle check()s durchgelaufen sind, werden alle aufgetretenen Exceptions von lcheck() geworfen.
      
      MfG
      - sid burn
        
        2009-05-29 16:15
        
        User since
        2006-03-29
        1520 Artikel
        BenutzerIn
        
        Guest MatthiasW
        Du könntest auch eine Methode(zB lcheck) hernehmen und mit Arrayreferenzen füttern. lcheck() führt dann für jede der Arrayreferenzen ein check() aus und fängt die Exceptions ab. Nachdem alle check()s durchgelaufen sind, werden alle aufgetretenen Exceptions von lcheck() geworfen.
        
        MfG
        
        Ja an sowas habe ich auch schon gedacht: http://www.perl-community.de/bat/poard/message/122...
        
        Allerdiengs gefällt mir die Lösung nicht so sehr. Am ende würde es vielleicht dann so aussehen um zwei benutzereingaben auf eine email zu prüfen.
        
        Code (perl): (dl )
        
        1 2 3 4
        
        $validate->aggregate([ { email => $user_input_1, $options_href }, { email => $user_input_2, $options_href }, ]);
        
        einzelne checks möchte ich z.B. so planen.
        
        Code (perl): (dl )
        
        $validate->email($user_input, $options_href);
        
        $options ist immer Optional. Würde ich es so wie oben machen hat man zwei unterschiedliche interface, einmal methode die den check angibt mit dem user input und optionale optionen. Und beim zusammenfassen mehrere checks auf einmal eine Datenstruktur.
        
        Schöner und konsistenter wäre es wenn es immer Methodenaufrufe sind.
        
        Ich denke gerade nach ob ich da irgendetwas mit caller() machen kann. Damit bekomme ich ja heraus ob mein vorgänger ein check war. Aber mir fällt nichts intelligentes ein wie ich das nutzen könnte oder einen Stack oder anonyme subs oder ähnliches so erstellen kann das genau das geht was ich möchte.
        
        Ich werde aber irgendwie nicht das gefühl loß das es irgendwie geht.
        Last edited: 2009-05-29 16:16:30 +0200 (CEST)
        Nicht mehr aktiv. Bei Kontakt: ICQ: 404181669 E-Mail: perl@david-raab.de
- +3 replies
- pktm
  
  2009-05-29 16:39
  
  User since
  2003-08-07
  2921 Artikel
  BenutzerIn
  
  Hallo!
  
  Nur so gefragt, was gefällt die Data::FormValidator nicht?
  Man kann dort alles von einfach bis hin zu komplexen validationsprofilen erstellen und prüfen. Außerdem gibt es eine Message-Methode, die die jeweiligen Fehlermeldungen benannter Constraints sammelz. Man kann sogar das hier:
  
  Quote
  If the built-in message generation doesn't suit you, it is also possible to provide your own by specifying a code reference:
  msgs => \&my_msgs_callback
  
  This will be called as a Data::FormValidator::Results method. It may receive as arguments an additional hash reference of control parameters, corresponding to the key names in the usually used in the msgs area of the profile. You can ignore this information if you'd like.
  
  If you have an alternative error message handler you'd like to share, stick in the Data::FormValidator::ErrMsgs name space and upload it to CPAN.
  
  Es gibt auch die Möglichkeit, mehrere Constraints für 1 Feld zu definieren:
  
  Quote
  Multiple constraints can be applied to a single field by defining the value of the constraint to be an array reference. Each of the values in this array can be any of the constraint types defined above.
  
  http://www.intergastro-service.de (mein erstes CMS :) )
  - +2 replies
  - sid burn
    
    2009-05-29 17:21
    
    User since
    2006-03-29
    1520 Artikel
    BenutzerIn
    
    2009-05-29T14:39:28 pktm
    Hallo!
    Nur so gefragt, was gefällt die Data::FormValidator nicht?
    
    Einiges. :)
    
    Quote
    Man kann dort alles von einfach bis hin zu komplexen validationsprofilen erstellen und prüfen.
    
    Das ist bereits das erste Problem. Du musst die ganzen profile und die Checks erstellen. Data::FormValidator ist für mich eher ein Framework für die Validierung. Aber es selber validiert nicht viel. Ich möchte auch die ganzen Validierungen nicht ständig neu erstellen.
    
    Ich möchte ein einfaches Modul haben das generell Daten validiert. Ist die übergabe ein INT?, POSINT?, in einem wertebereich? ist es eine E-Mail Adresse? Eine Domain? Ein Datum?
    
    All diese Checks musst du bei Data::FormValidator selber erstellen. Ich möchte etwas haben womit der Nutzer alle diese fertigen Validierungen einfach nur aufrufen kann. Es ist also bereits eine fertige Sammlungen von allen Möglichen Validierungen die es gibt.
    
    Ansonsten sollen am ende natürlich auch Filter und Transformationen gehen. z.B. ein Filter der Werte vor dem check bearbeitet. z.B. Whitespace zeichen vorne und am ende entfernen.
    
    Und unter Transformation meine ich sowas wie bei Moose "Coercion" das ich sagen kann, validiere es und wenn es ein Datum ist mache daraus ein DateTime objekt etc. Alles schon fertig gebaut, einfach anwendbar ohne das man die hälfte selber coden muss!
    
    Und "einfach" ist auch so ein Punkt, ich finde Data::FormValidator nicht einfach. Es stehen da knapp 10 Seiten Doku und man sieht nichtmal wie man schnell prüft ob ein Wert eine E-Mail adresse ist.
    
    Ansonsten möchte ich eine allgemeine Validierung haben, die z.B. nicht an Web gebunden ist. Praktisch also eine unterlage die andere Systeme nutzen können.
    
    Die Checks selber implementiere ich nicht alle neue sondern möchte ebenfalls fertige Module nutzen wie. "Regexp::Common", "Email::Valid" etc. allerdiengs werde ich das so abstrahieren das alles über ein "einheitliches Interface" ansprechbar ist. Data::FormValidator bietet dir da nichts. Du musst die Module weiterhin so nutzen alle mit einen eigenen Interface.
    
    Alle Fehler "müssen" Exceptions werfen. Ich baue mitlerweile alles so auf das bei Fehler Exceptions kommen. Da man damit sehr viel sauberer Programmieren kann und Fehler einem nicht "entfliehen". Das man eine eigene Code Referenz angeben kann ist toll. Ich möchte aber nicht erst einen Haufen Code schreiben damit dies geht, sondern es sollte von Haus aus gleich so sein. Stichpunkt einfachheit.
    
    Ansonsten geht es mir nicht nur darum einfach nur Exceptions zu haben, sondern die Exceptions müssen alle nötigen Informationen enthalten. Den der Punkt ist. Validierung und Exception Handling passieren nicht an den gleichen Orten.
    
    z.B. in einem Modul das Daten in die Datenbank schreibt prüfst du vor dem schreiben in der Datenbank ob die Werte Valide sind. Allerdiengs fängst du die Fehler dort nicht ab. Die Fehler fängst du an einer höheren ebene ab, nämlich beim aufruf der Funktion in die datenbank zu speichern (oder sogar noch woanders).
    
    Data::Formvalidator ist so aber nicht gebaut. Data::FormValidator validiert aber die daten wo etwas invalide ist rufe ich dann über das objekt auf, das objekt was ich in einem anderen Scope aber gar nicht mehr habe.
    
    Weiterhin sind mir die Daten die es zurükliefert zu mau. z.B. invalids() liefert nur die Feldnamen zurück die invalide waren. Da das validieren und checken aber an ganz anderen Stellen passiert weiß ich nichts beim abfangen welche Daten eingegeben wurde vom nutzer. Sondern all diese Daten müssen in den Exception Objekten übergeben werden.
    
    Weiterhin sollen Die Checks auch immer Konfigurierbar und anpassbar sein.
    
    Bisher habe ich kein Modul gesehen das mir alle diese Punkte erfüllt.
    
    Ich bin aber noch in der Plannungsphase des Moduls.
    Last edited: 2009-05-29 17:45:25 +0200 (CEST)
    Nicht mehr aktiv. Bei Kontakt: ICQ: 404181669 E-Mail: perl@david-raab.de
    - pktm
      
      2009-05-29 19:19
      
      User since
      2003-08-07
      2921 Artikel
      BenutzerIn
      
      Ja, in dem Punkt mit der Einfachheit stimme ich dir uneingeschränkt zu. Die Doku ist ein wesentlicher Grund, warum die Sache nicht einfach ist.
      Ich habe lange benötigt, da durch zu steigen und ich kann immer noch nicht mal eben jede Funktion benutzen.
      
      Aber: vieles von dem was du haben möchtest ist bereits da.
      Data::FormValidator::Constraints enthält z.B. eine Sammlung diverser Constraints, deren Erweiterung sich sicher lohnen würde (z.B. solche Constraints wie "ist Integer").
      Desweiteren ist DFV nicht nur für Web-Daten da. Davon aht es sich gelöst. Man kann alles mögliche an Datenvalidieren.
      
      Ich denke, mit etwas Arbeit am Modul DFV kann man das, was du erreichen möchtest, umsetzen. So hat man keine zwei guten Module, sondern ein gutes. Mich jedenfalls würde es freuen, sowas in DFV zu sehen.
      http://www.intergastro-service.de (mein erstes CMS :) )

View all threads created 2009-05-29 14:17.