[PHP5] FORMCHECKER : VALIDATION DE SAISIES UTILISATEUR
FhX
Messages postés
2350
Date d'inscription
mercredi 13 octobre 2004
Statut
Membre
Dernière intervention
18 avril 2015
-
5 janv. 2007 à 15:46
Phelim Messages postés 1 Date d'inscription mercredi 26 avril 2006 Statut Membre Dernière intervention 1 mars 2008 - 1 mars 2008 à 21:30
Phelim Messages postés 1 Date d'inscription mercredi 26 avril 2006 Statut Membre Dernière intervention 1 mars 2008 - 1 mars 2008 à 21:30
Cette discussion concerne un article du site. Pour la consulter dans son contexte d'origine, cliquez sur le lien ci-dessous.
https://codes-sources.commentcamarche.net/source/40984-php5-formchecker-validation-de-saisies-utilisateur
https://codes-sources.commentcamarche.net/source/40984-php5-formchecker-validation-de-saisies-utilisateur
1 mars 2008 à 21:30
C'est extrêmement complet et efficace.
Par contre, je ne vois pas forcément l'intérêt des fonctions d'utilisateurs.
Il est facile et plus propre de réaliser d'autres classes de validation ou d'étendre les class existantes.
Etant donné que tout est bon ( convention de codages, documentation, modularité ), je donne la note maximal a cette source
11 juil. 2007 à 23:45
En bref, du trés bon travail !
27 janv. 2007 à 15:24
Pour revenir à l'anglais, le truc c'est que je commente mes codes en anglais. Je me vois mal faire 2 fichiers, 1 avec le code commenté en anglais et 1 avec le code commenté en français, spécialement pour CS.
L'anglais que j'utilise est super basique, bourré de fautes parce que je commente généralement très vite sans faire particulièrement attention, et donc à priori compréhensible même si on est mauvais en anglais ;-)
27 janv. 2007 à 11:22
25 janv. 2007 à 13:13
Voila @
24 janv. 2007 à 19:18
Epoc22 => je ne partage pas forcément QUE pour des français...je ne travaille pas non plus forcément QU'AVEC des français...
Donc, je documente en anglais.
Et ça, même la semaine prochaîne, je ne le changerai pas ;-)
Ceci dit, tu noteras que dans le zip, il y a une documentation sur l'utilisation en français, hein...;-)
24 janv. 2007 à 18:12
C'est comme ca, faut t'y faire :)
24 janv. 2007 à 17:03
c'est un peu chiant la doc est en anglais...
12 janv. 2007 à 19:56
Verrai ça la semaine prochaine (si tout va bien lol).
12 janv. 2007 à 19:19
9 janv. 2007 à 20:37
FormChecker::validate();
public function validate ($mString, $sName, $cPattern, $aOptions null, $bMandatory true);
Alors..., je décortique :
$mString, c'est la chaine à traiter.
$sName, c'est le nom que tu vas donner à ta chaine (pourquoi ? va savoir :s)
$cPattern, c'est le type de classe que tu vas instancier (hu ? )
$aOptions, ce sont les options de ta classe (la aussi... hu ?)
$bMandatory, encore une autre option un peu spécial.
Orienté objet, y'a comme une erreur la dedand. Tu fais passer en paramètre le type de classe ainsi que les options séparément ?
Pourquoi tu n'as pas retenu mon idée d'origine, c'est à dire de faire :
public function validate ($oObject, $bMandatory = true);
Avec :
$oObject, la classe d'objet instanciée.
$bMandatory, ton option "spéciale".
?
Ton constructeur d'objet devra ressembler à ca :
public function __construct($mString, $aOptions=NULL);
Et pour appeler ta méthode formchecker::validate(), suffit de faire :
return ( $oFormChecker->validate( new validateInt(95000) ) ) ? TRUE : FALSE;
C'est pas plus facile à lire ? A coder aussi je crois non ?
C'est peut être plus lourd niveau temps d'exécution alors ?
Parce qu'après, le code de FormChecker::validate il ressemble à ca :
public function validate($oObject, $bMandatory=TRUE) {
try {
$bRes = $oObject -> validate ($bMandatory);
} catch (Exception $e) {
self::$aMsg[$sName] = $e -> getMessage ();
$bRes $this -> bValid false;
}
return $bRes;
}
En plus, je suis sur que tu peux te passer de cette classe formchecker... Mais c'est une autre histoire.
Tu peux essayer ma méthode pour voir ? Pas trop le temps en ce moment pour te pondre tout le code mais jvais essayer de le faire à ma sauce et faudra juste que tu me le bench par contre :p
8 janv. 2007 à 09:27
C't'en ligne :-)
7 janv. 2007 à 15:54
T'es pas un vrai Geek du PHP Mala... rahhhh :p
6 janv. 2007 à 11:02
Donc ce sera lundi :-)
5 janv. 2007 à 21:34
Fait envoyer le nouveau code maintenant... doit y avoir encore des trucs à parfaire :D
M'est avis que tu seras toujours un peu plus lent que ton bouzin d'avant ... quoi que :/
Jvais m'y pencher demain ^^
Envoi le nouveau code quoi !! Aller ! :p
5 janv. 2007 à 19:35
Je regarde ma propriété (validateGen::$sloc) est différente du paramètre passé, si oui, j'instancie sLocClass, sinon non. Comme ça on peut changer de languer au sein du même script (ce qui est, convenons-en, assez peu probable, mais bon...).
Ben en fait là, je suis tjrs plus lent qu'avec la classe originale.
Mais c'est plus joli ;-) (je mettrai à jour la semaine prochaine).
J'ai mis, donc : bcp de méthodes en statique, la propriété sLocClass, j'ai passé en privée quelques méthodes aussi, et j'ai foutu les exceptions à la place des formChecker::$aMsg...bla bla, que j'ai juste mis dans le catch.
Le code est aussi un peu plus court.
Reste à retrouver la vitesse d'antan lol...mais on verra. Suis passé de 0.00086... à 0.00095 en moyenne, au final.
Donc je perds 0.0001 seconde sur ce petit script (la version française uniquement, c'est ce que j'ai benché). Pas énorme de toute manière.
Donc oui, l'optimisation à la FhX a fonctionné à merveille ;-)
5 janv. 2007 à 18:53
Pour if ( !isset(self::LocClass) ) self::LocClass = formCheckerMessages::factory ($loc); j'avais oublié de te dire que étant donné qu'on appèlle la même classe à chaque fois, ca fait une instance à chaque appel :p Bah vi, c'est un Singleton ca... :p
Et voila :) Chui content d'avoir eu raison sur le statique... j'ai eu peur quand tu m'as dit que ca prenait plus de temps :o
5 janv. 2007 à 18:38
Du coup j'ai 3 cas dans la méthode validate de la classe mère. Mais ça ne me plait pas non plus...je n'ai juste pas trouvé d'autre moyen.
En fait l'intérêt de scinder autant est que si jamais je n'ai que une donnée de type texte à vérifier (ou 2), je ne récupère pas des méthodes inutiles dédiées aux emails, url, type numériques etc...
De plus, cela facilite l'évolution des classes, et la création de nouvelles classes. Le processus est implémenté, et ajouter un masque, par exemple, demande juste l'implémentation d'une classe fille. Et tout le reste est déjà géré.
Lors du dév de ce package, ça s'est révélé très efficace par rapport à ma méthode d'avant qui regroupait tout en une classe (ou presque).
Ca, je garde mes petites classes filles lol ;-)
Par contre j'optimise (bon là ce n'est pas flagrant, j'ai perdu un peu de rapidité...mais y a des exceptions lol et c'est encore plus facilement gérable...mais j'espère arriver à plus optimisé).
Et au niveau de l'utilisation en elle-même, une fois qu'on a compris comment se faisait les appels de masque avec les options (ça ok, c'est pas évident..mais en même temps c'est plutôt puissant), c'est très facile à implémenter dans un code.
mais je suis d'accord, c'est loin d'être parfait. En fait, je vais approfondir le côté Reflection, parce que je pense qu'on peut gagner du temps avec (j'en suis pas certain non plus hein...).
5 janv. 2007 à 17:46
@ tchaOo°
5 janv. 2007 à 17:41
Sinon... dans les classes filles de validateGen
if (false ($bRes parent::validate (... .. .))) {
return false;
} elseif (true === $bRes)
$bRes ne peut être que booléen il me semble... alors pourquoi un double test... .. ?
@ tchaOo°
ps : bonne année à vous deux... .. .
5 janv. 2007 à 17:32
Par contre, je vais voir pour tes exceptions...en effet, et gérer ça en dehors avec un bloc try catch.
Pour le reste on verra! Je vais voir ce que je peux faire par rapport à la réflexion...le problème à la base était de récupérer mes constantes. Evidemment, si je m'en passe...je peux aussi me passer de la réflexion. mais j'aimais bien l'idée des constantes de classe pour appeler les masques lol.
5 janv. 2007 à 16:39
Après avoir pris ma douche et tout et tout... voila comment j'aurais fait :p
*****
*****
Je vais prendre ta classe validateUrl :
class validateUrl extends validateGen {
private $mString;
private $sName;
private $aOptions;
private $bMandatory;
public function __construct($mString, $sName, $aOptions=NULL, $bMandatory=TRUE) {
$this->mString = $mString...; // etc...
}
public function validate() {
if ( !parent::validate() ) {
return false;
} else {
// if pregmatch...()
}
}
}
// Puis dans formChecker::validate();
class formchecker {
public function validate ($oObject) {
if (false ($bRes $oObject -> validate () ) ) {
$this -> bValid = false;
}
return $bRes;
}
}
// et dans ton exemple :
if (false === $oChecker -> validate (new validateUrl($sUrl, 'url') )) {
// etc...
} else {
// etc...
}
Voila un peu comment je voyais ca :)
Dans la théorie, c'est censé fonctionner... ca nécessite de remanier un peu le code dans la classe abstraite mais voila à peu près les grandes lignes :)
5 janv. 2007 à 15:46
# * @return unknown
# */
# public function isValid () {
# return $this -> bValid;
# }"
C'est ca oui ...
@return unknown sur une variable boolean ? ;)
J'aime bien pour ma part (apparament, t'a tué tout le monde, personne vient poster :p)...
Juste que c'est un poil trop lourd je trouve.
Surtout au niveau du :
# $oReflect = new ReflectionClass($cPattern);
# $o = $oReflect -> newInstance ();
Parce que tu vas faire une instance de validateUrl par exemple et qui va récupérer TOUTES les méthodes de ta classe abstraite, et puis une autre instance de validateInt par exemple et qui va elle aussi récupérer TOUTES les méthodes de ta classe abstraite INDEPENDEMENT de l'instance "validateUrl".
J'imagine la duplication de code en mémoire lorsque tu instancies toutes les classes filles :)
Je pense que certaines méthodes dans ta classe abstraite doivent passer en statique car elles sont communes à toutes les instances au final... y'a pas une grande spécificité entre les instances.
Si je peux te donner un conseil, c'est celui la. Passer les méthodes en statiques (ca va t'obliger à revoir un peu le code par contre ^^) et puis je pense que c'est tout.
Si, y'a peut être autre chose, mais ca on verra plus tard, jviens de me lever et j'ai faim ^^
Ah vi, fait un bench de ton exemple avant de mettre quoi que ce soit en statique (donc tes classes en l'état), et essaye après. Normalement, tu récupères un peu de ces precieuses millisecondes :p (et surtout un peu de mémoire aussi ^^).
Cependant, le concept est pas mal en lui même, tout est fonctionnel... mais peut être un peu dur à comprendre du premier coup pour quelqu'un qui pige quedalle (surtout au niveau des arguments de ->validate() :p)
Si j'ai le temps, je t'expose mon autre théorie dans la journée... tu vas voir ^^