Classes et vérification des données

Bonjour à tous,

Je viens pour poser une question peut-être stupide, mais je voudrais savoir s'il est plus intelligent et maintenable de vérifier les données saisies par un utilisateur directement sur la page php qui contient le formulaire de saisie ou dans la classe qui traite à proprement parles ces données (insérer, modifier des enregistrements dans une base de données).
Mon autre question est: si j'ai une classe permettant de vérifier des types de données (adresse e-mail valide, que du texte....) puis-je l'appeler depuis une autre classe sans que ça ne soit trop lourd en terme de temps de traitement s'il y a de nombreux utilisateurs connectés?
Si quelqu'un pouvait me faire part de son expérience... ça serait sympa.

(caractéristiques du projet pour lequel celà s'applique: application web en php 4, base de données MySQL, 500 clients simultanés maximum).
Merci.
TTMan

Pour vérifier la validité d'un formulaire, tu peux le faire en Javascript avant l'envoie définitif de ce dernier. Avec le javascript, et en travaillant bien tu peux vérifier si tel ou tel champs est renseigné, ou si une adresse email est valide, ou même un numéro de téléphone ... Sinon, si tu veux faire des vérifications poussées dans ta base de données, sors un peu d'AJAX ;-)

Cordialement,
Kdecherf

Hello,

ça ne répond pas à la question, et donne de mauvais conseils.
Fais tes vérifs en javascript, comme ça, le mec malintentionné désactivera javascript et fera passer ce qu'il veut dans le formulaire.

Perso, j'ai une clsse de vérification et d'assainissement de données.
Elle est totalement indépendante de ma classe d'avstraction de base de données.
De même, je n'ai pas de classe insérant les données de mon formulaire danns une bdd, par exemple...une classe n'est pas faite pour quelque chose d'aussi spécifique. Une classe est un outil, pas une finalité (à mon sens).
Bref, j'affiche mon formulaire...il est soumis, les donées sont assaisinies et vérifiées en utilisant les méthodes de ma classe de traitement de données...pouis, par exemple, j'insère les données en bdd en utilisant ma classe de bdd (j'entends  par là : query (), et c'est tout...pas : insertIntoDbFormResult()).

Rah ... Je ne fais que proposer ...

De plus, rien n'est parfait. De même, il suffit de refuser d'envoyer le formulaire si le javascript est désactivé.

Mais bon, chacun son chemin après ...

Cordialement,
Kdecherf

Moi, mon "assainissement" pour une insertion en bdd se fait dans la classe sql. Je me suis fait mon propre parseur pour traiter mes données donc... :)

Après, moi j'ai bien une classe pour l'insertion de news ou autre. On appèle cela une factory.
Un factory, bien developpé, peut être ré-utilisable pour n'importe quoi.

Par exemple, je me suis basé sur ca :

classe abstraite "factory"

classe abstraite "factory-news" étendant "factory"
classe concrète "news-sql" étendant "factory-news"
classe concrète "news-xml" étendant "factory-news"

classe abstraite "factory-commentaires" étendant "factory"
classe concrète "commentaires-sql" étendant "factory-commentaires"
classe concrète "commentares-xml" étendant "factory-commentaires"

classe abstraite "factory-dossier" étendant "factory"
etc...


Je ne parle même pas des intérfaces pour gérer tout ca de manière autonome.
Ce qui fait que quand j'appèle une factory, j'ai beaucoup de méthodes communes (ajout, suppression, modification), ce qui fait que j'ai une homogénité entre mes factorys.

Je peux faire un :
$news = new news-sql();
$news->add(....);
$comment = new comment-sql();
$comment->add(...);

etc....

L'uniformisation au maximum.
Faudrait que je poste tout ca un jour :)


Cependant, pour en revenir au sujet, si tu veux faire une classe d'assainissement... autant le faire dans une classe type "factory" et mettre les méthodes d'assainissement en statiques. Ex d'assainissement :
Dans ma classe abstraite "factory", je met une méthode en statique pour faire du strip_tags() et un htmlentities(). Rien de plus simple :

static public function _clean($var) {
 return htmlentities( strip_tags($var) );
}

Et non seulement elle en sera chargé qu'une seule fois en mémoire (principe du statissisme), mais elle sera accessible dans la classe elle même et aussi hors classe sans instanciation.
De ce fait, je peux faire quelque chose comme :
news-sql::_clean($myvar);
ou alors :
commentaires-sql::_clean($myvar);
ca marche pareil :)

Voila voila :)

Là, on est d'accord, si on parle en modules. Effectivement, j'ai aussi des appli fonctionnant avec des modules...même si c'est un peu différent. Un objet documents, par exemple, étendu par un objet pdf, ou un objet email, et des méthodes communes abstraites définies dans l'objet parent commun document : create, edit, save, etc...(en fait, tout ça venant d'autres objets plus haut encore : output, input...).
Et dans ce cas, chaque objet gère ses méthodes d'écriture par exemple : le log sera en fichier xml, une demande s'écrira dans la bdd etc...
Pourquoi pas,c'est une façon de coder.
Même si j'ai tendance à préferer l'utilisation d'ibjets bien plus abstraits, aidant à définir peu à peu des objets plus spécialisés.
Objets spécialisés qui sont au final tout petits et tout simples, vu que la plupart de leur méthodes sont définies en amont.

Mais ce dont je parlais, c'est ce que l'on voit trop souvent : un objet DB, qui gère les accès, méthodes db (fetch_row, query, etc), Et des méthodes annexes gérant le site du genre insertNews, insertUser etc...là, je ne suis pas d'accord. L'objet user se gère tout seul, aidé par l'objet db le cas échéant. Idem pour les news etc...

Mala, y'a moyen que tu puisses m'envoyer ca par MP ou pas ?
Ta gestion de module je parle... c'est possible ou ca reste dans ton cadre pro ? Sinon tant pis.

Mais si je peux te donner un conseil :
"et des méthodes communes abstraites définies dans l'objet parent commun document : create, edit, save, etc..."
Utilise des interfaces pour ca :p


D'ailleurs, j'avais essayé de faire une interface commune sql/xml, mais ca oblige à consommer plus de ressource. Le simple fait de tout récupérer dans un tableau que ce soit pour xml ou sql est une vraie plaie.


Parce qu'au final, tout ce qui est input/output (classe de db, classe xml, classe de fichiers...) doivent avoir les mêmes interfaces pour être vraiment utilisable.
Imaginons une grosse factory style news... plus besoin de spécialiser la factory, tu passes l'objet en paramètre du constructeur et c'est parti :)

Jvais continuer sur cette voie. Si j'arrive à faire une interface commune xml/sql (donc utiliser xquery/xpath (ca va être marrant tiens...) ), ca sera beaucoup plus simple par la suite.


D'ailleurs Mala, toi qui connait mieux XPath que moi, tu sais comment faire pour récupérer un morceau comme le fait un *_fetch_array() pour sql ?

:)

Merci à tous,
au vu des réponses, je pense que je me suis aussi assez mal expliqué.
J'ai un "objet" client, auquel j'ai cré une méthode intitulée "AjouterClient". Elle est copiée ci-dessous.

function AjouterClient()
{
            // Récupération de la date du jour et mise en mémoire
            $this->date_creation = date('Y-m-d');//'2007-01-01';
            // Ajout d'un client dans la table Clients
            mysql_query("INSERT INTO " . table_clients . " VALUES('', '', '$this->nom', '$this->prenom', '$this->adresse', '$this->code_postal', '$this->ville', '$this->pays', '$this->telephone', '$this->email', '$this->residence_station', '$this->telephone_station', '$this->date_creation')") or die('Problème de requête: ');
}

A l'heure actuelle dans mon code je procède comme suit:

$nouv_client = new Client();
ensuite j'affecte des valeurs aux différentes propriétés de mon objet puis j'appelle la méthode "AjouterClient".
Pour l'instant je vérifie les données avant de les affecter aux propriétés, mais quesiton maintenabilité je trouve pas ça top.
Je pense utiliser une classe comme le suggèrent FhX et malalam.

Le javascript, je l'utilise pour une première vérification côté client, histoire de ne pas surcharger les aller/retour serveur, mais je préfère vérifier encore avant de mettre dans la BDD... et là c'est du pur PHP :-)