Reprise du message précédent :
Pourquoi ne pas utiliser un ORM comme PHPDoctrine ?
www.phpdoctrine.net
 
Très simple à utiliser, puissant et surtout très bien documenté

...ou au moins PDO...

Tout à fait, d'ailleurs PHPDoctrine est basé sur PDO

 
Tu aurais des exemples concrets ?

 
Y'en a pleins la doc des exemples

Tiens ça à l'air marrant ça Ca va dans le sens où tout le monde va, avec une fluent interface et tout

 
Je lui ais dit pareil dans un topic qu'il avait crée sur le meme sujet  

On n'avait pas parlé i18n et l10n ici ? Un article ultra-intéressant vu sur reddit sur les problèmes associés : A Localization Horror Story: It Could Happen To You
 
Je crois que je vais me tourner vers une solution classe avec constantes, plus des fonctions pour gérer les cas spéciaux.

Débat du jour : Où foutre la validation des formulaires ?

Mes deux hémisphères cérébraux sont en conflit : l'un pense qu'il faut mettre la validation des formulaires dans le model, l'autre pense que ça va dans le controller...

Code Igniter permet de mettre un callback dans le controller pour faire de la validation supplémentaire. CakePHP, lui, place tout ça dans le Model.

Dans mon framework, c'est pour l'instant assez le bordel. J'ai une vague validation déclarée dans le formulaire lui-même, et après à moi de faire ce que je veux. Pour l'instant, j'ai presque tout fait dans les models.

Qu'en pensez-vous ?

C'est le model qui vérifie la validité des données.

Que ça dépend de ce que tu veux faire de tes données de formulaire.
 
Si c'est pour les balancer dans du modèle, genre tu resérialises en DB, conneries du style, alors validation dans le model, si c'est pour gérer ou effectuer des actions, validation dans le controller.

Quelques éléments de réfléxion dans Where to put validation in the MVC pattern (en)

Marrant que les devs de code igniter ont tout foutu dans le controller...
 

Ca c'est sûr. J'ai parfois de la validation lorsque c'est des paramètres. Genre l'affichage d'un produit correspondant à un id. Je vérifie si l'id est numérique et existe dans le controller. Si c'est pour de l'insertion, c'est dans le modèle.

J'vois pas l'intérêt, tu fais ta requête et tu regardes si t'as reçu un truc oui

C'est pour un message d'erreur un peu plus explicite. Maintenant ça dépend des cas, parfois je balance la requête cash.

Ils font pas mal de trucs crades, donc je doute qu'on puisse s'appuyer sur leurs choix pour prendre une décision.
 
Quand tu veux insérer une personne dans une base de données, c'est le model que tu intérroges pour vérifier l'existence d'une personne avec le même nom et ou le même email.
 
Donc partant de la, et sans reflexion sur-édulcorée, je le mettrais dans le model.

C'était pour moi le plus logique. Maintenant en voyant ce qu'ils ont fait dans CI, et étant de nature à tout remettre en question... Je vais partir là-dessus, et améliorer mon API pour la validation de données, et ça roule

Ce framework ne t'empeche pas non plus de faire ca dans le modele.

J'ai jamais dis le contraire  

Mmh, c'est surtout FlorentG qui disait que "les devs ont tout mis" dans le controlleur, alors qu'on est libre de faire ca dans le modèle.
 
Sinon personellement même si c'est vrai que la conformité des données est définie dans le modèle je trouve pas illogique de traiter les données à passer au modèle par le controlleur et donc à les valider.

Ok, j'ai regardé ça un peu en vitesse, effectivement

Perso je considère que la validation fait partie du dialogue entre la vue et le controleur...et qu'il peut y avoir des contraintes de saisie n'ayant rien à voir avec le modèle.

Par exemple le format de saisie d'une date, au pif...le modèle n'en a rien à foutre, a priori.
De la même manière on peut avoir des règles de gestion complexes à traiter, du genre une valeur n'est acceptable pour un champ que suivant la valeur d'un autre, etc...tout ça me parait difficilement relever du boulot du modèle.

Y'a aussi le cas genre lors de l'inscription sur un site, le champ "mot de passe" et "retapez le mot de passe", est-ce au modèle de vérifier que les deux mots de passes sont les mêmes ?
 
Pour l'instant je teste ça dans le modèle, mais c'est vrai que c'est un peu ambigü...

 
Pour moi c'est pas le boulot du modèle, effectivement.
Par exemple si tu décides de ne plus le faire saisir 2 fois mais de le faire saisir en clair, ou que tu décides d'ajouter un captcha, tu vas pas changer ton modèle, non?

Au mieux le modèle pour fournir des règles sur ce qu'il connait (taille et type des champs dans la base, par exemple, ou paramètres dans les fichiers de conf).

Pour moi ce cas là c'est au controleur de le vérifier. Le modèle il a juste connaissance de la notion du "mot de passe" pas de la notion de la "confirmation du mot de passe".
Le modèle s'en fout du fait que t'ajoutes un champ de confirmation (ou 12 champs de confirmation ) pour une donnée.

En résumé, il faut splitter la validation des données. Certaines règles appartiennent au modèle, d'autres au controller. Le problème maintenant est de définir qui valide quoi.
 
On va prendre le cas d'un modèle mysql. Lui ne s'occupera que de valider en vue de son schéma de table : type de champ, longueur, vérification de champs dupliqué. On aura par exemple le code suivant  :

class modele_user_mysql {
 
  /**
   * Vérification d'un nouvel utilisateur
    */
  public function validationUtilisateur($user)
  {
      if(strlen($user['name']) > 20) {
          $this->setError('Le nom d\'utilisateur ne peut dépasser 20 caractères');
      }
      
      if(strlen($user['pass']) < 6) {
          $this->setError('Le mot de passe doit être supérieur à 6 caractères');
      }
      
      if(mysql_num_rows(mysql_query('SELECT * FROM `users` WHERE `email`=\'' . mysql_real_escape_string($user['email']) . '\'')) > 0) {
          $this->setError('L\'adresse e-mail est déjà utilisée');
      }
      
      // etc.
  }
  
}

 
Maintenant le controller s'occupe de la validation concernant uniquement le formulaire : vérification que deux champs sont égaux (mot de passe), qu'un champ dépendant d'un autre satisfait une condition, etc. Code exemple :

class controller_user {
    
    public function post($data)
    {
        $this->validation($data);
        $this->modele->validationUtilisateur($data);
        
        // etc...
    }
    
    
    private function validation($data)
    {
        if($data['pass'] !== $data['passConfirm']) {
            $this->setError('Les mots de passes doivent être les mêmes');
        }
    }
    
}

Pas forcément.
On peut considérer que les règles de validation font partie du modèle, mais que le contrôleur les demande au modèle et fait la validation.
Après tout une règle de validation telle que la taille maximale est une donnée du modèle comme une autre...que le contrôleur doit pouvoir récupérer pour en faire ce dont il a besoin.

C'est un peu se que je fais en appellant la méthode validationUtilisateur sur le modèle, on demande au modèle de valider des données.
 
Après on pourrait avoir un objet style "Validator" que le modèle instancierait avec les bons paramètres, et le controller l'utilise pour valider et récupérer certaines règles.
 
On pourrait par exemple avoir une règle style "pas plus de 20 caractères", le controller récupère ça et le transmet à la view, qui elle-même rajoute un 'maxlength="20"' sur le bon input

 
Voilà, c'est plutôt ça que je voulais dire.
Des méthodes genre getMonChampTotoValidator(), et le controleur les utilise pour construire un FormValidator...

Je vais partir dans cette idée, ch'uis en train de faire une classe Validator et tout, ça va rosquer

 
Quand t'as fini je ramasse les copies, j'ai un machin avec 5 pages de formulaires à refaire proprement.

C'est closed-source Je vendrais ma classe 10€ avec les tests unitaires.
 
 
Sinon je vais aussi rajouter la normalization des données : certains champs doivent être trimmés, on doit y virer les retours chariots, etc.

 
Ca fait des mois que j'ai commencé ces classes dans un coin et que j'ai pas eu le temps de les terminer...

J'avais aussi plein de trucs comme ça en chantier. Mais maintenant que j'ai une dizaine de modèles, avec plein de formulaires partout, le besoin s'en fait ressentir : marre de faire des strlen(trim()) dans tous les sens et de se retapper la même chose à chaque fois.

J'sais pas pourquoi j'suis ici, php c'est laid

GTFO Ou au moins participe au débat

Bon, je m'oriente vers une fluent interface, style :

Je fais tout en TDD, c'est quand-même pratique.

 
Au pif je dirais que chaque méthode retourne l'objet mis à jour