Validierung von Daten

[daddz]

Im Laufe der Arbeit am FaDzFilter ist eine Funktion enstanden um diverse Daten zu validieren, da es mich immer genervt hat hier und da irgendwelche Schnipsel zu verwenden und dann im Code viele verschiedene Funktionen umherfliegen zu haben.

Ich dachte mir, dass ihr die Funktion vielleicht auch um ein paar weitere Datenarten erweitern könntet:

function is_valid($input, $type, $param = null) {
	
    switch($type) {
	
    	case 'string':
	        return ((!empty($input)) && (is_string($input)) && ($input == strval($input))); 
	
    	case 'int':
	        return ((is_numeric($input)) && ($input == intval($input))); 
	
    	case 'float':
	        return ((is_float($input)) && ($input == floatval($input)));
        
        case 'object':
            if(is_object($input)) {
               if(!is_null($param)) {
                    return ($param == get_class($input));                
                }
                return true;
            } else {
                return false;
            }
        
        case 'email':
            return preg_match('#\b[A-Z0-9._%-]+@(?:[A-Z0-9-]+\.)+[A-Z]{2,4}\b#i', $input);
        
    	case 'ip':
	        return preg_match('#\b(?:\d{1,3}\.){3}\d{1,3}\b#', $input);
	
    	default:
	        return false;
	
    }
    
}

Zur Erklärung der Parameter:

• $input = Daten die validiert werden sollen
• $type = Datentypen die es bis jetzt unterstützt:
  • string
  • int
  • float
  • object
  • email
  • ip
• $param = Extraoptionen wie z.B. Name eines Objekts, dass validiert werden soll

Die Benutzung sieht folgendermaßen aus:

if(is_valid($einText, 'string')) { 
    // ... mach was
}

Um die Bedeutung des letzten Parameters $param nochmal zu verdeutlichen:

if(is_valid(&$einObjekt, 'object', 'UnserTestObjekt')) {
	// ... mach was
}

Bei dem Beispiel gehe ich also davon aus, dass das Objekt 'UnserTestObjekt' heißt.

Ich hoffe das ist alles soweit klar und ich würde mich über Erweiterungen freuen!

 

[Flex]

Hm, spontan nein

Aber mir ist aufgefallen, dass du bei deinem regulären Ausdruck für die E-Mailadressen einige Domains ausschließt:
.museum
.travel

Klar sind es nicht viele, aber der Trend geht ja zu immer obskureren TLDs.

 

[Radhad]

Datumsangaben wären vielleicht noch Interessant. Ich weiß jetzt nicht ob nur DD.MM.YYYY unterstützt werden soll oder auch andere wie MM/DD/YYYY aber ich denk das würde sich noch lohnen

 

[Gumbo]

Die Frage ist, ob es wirklich sinnvoll ist, jedes noch so unterschiedliche Datenformat zu berücksichtigen.


Deine Funktion ist übrigens nicht gerade sehr präzise. Denn bei der Zeichenkettenprüfung wird eine Zeichenkettennull („"0"“) als ungültig bewertet. Bei der Integerprüfung hingegen rutscht „0.0“ (also eigentlich eine Gleitkommazahl) durch. Oder ist dieses Verhalten gewollt?

 

[daddz]

Die Frage ist, ob es wirklich sinnvoll ist, jedes noch so unterschiedliche Datenformat zu berücksichtigen.

Es soll lediglich eine Sammlung verschiedener Möglichkeiten sein, um mal alles in einer Funktion zu haben.

Deine Funktion ist übrigens nicht gerade sehr präzise. Denn bei der Zeichenkettenprüfung wird eine Zeichenkettennull („"0"“) als ungültig bewertet. Bei der Integerprüfung hingegen rutscht „0.0“ (also eigentlich eine Gleitkommazahl) durch. Oder ist dieses Verhalten gewollt?

Genau deshalb habe ich die Funktion hier reingestellt, damit ihr mir helft sie etwas zu verbessern.
Der "Fehler" wäre mir dadurch garnicht aufgefallen! :suspekt:

Aber mir ist aufgefallen, dass du bei deinem regulären Ausdruck für die E-Mailadressen einige Domains ausschließt:
.museum
.travel

Naja, ich denke, dass man nicht all zu oft mit derartigen Domains zutun hat. Aber natürlich ließe sich soetwas einbauen!