Reprise du message précédent :

C'est à dire soit soi même soit un nouvel objet (quand la fuent interface fonctionne sur de l'immutable, ce qui est l'idéal )
 
Pour le post originel sur le sujet: http://martinfowler.com/bliki/FluentInterface.html

Tu pourrais n'avoir qu'une classe qui gère l'affichage et la validation, non ?
Parce que là, t'as quasi répéter deux fois la même chose dans Validator et Form.

1. min() et max() sont toujours utilisés ensemble, ça fait une redondance que je trouve con, je conseillerais de créer une méthode between() pour gérer cette partie

2. isRequired() donne l'impression qu'on demande si le champ est requis, et dans la majorité des langages n'ayant pas de caractères non-ascii, c'est ce qui se passe. Ajouter un paramètre booléen pour bien montrer qu'on set quelque chose (et pas qu'on le demande), ou changer le nom  de la méthode (en setRequired() par example).

3. J'aime pas trop l'interface pour ajouter des champs aux forms, perso j'aurais séparé ça, un truc du style:

new Form('log','index.php','POST')
-> add(new TextInput('login')->between(3, 15)->setRequired())
-> add(new Password('passwd')->between(6, 20)->setRequired())
-> add(new Checkbox('persist')->setChecked())
-> write();

Et accessoirement, je me rends compte que le "min/max" et le "between" ne sont pas bien explicites sur le fait que c'est une longueur et pas un bound pour les valeurs, préfixer avec "length" imho. Et TextInput est trop lourd, "Text" suffit.

Enfin, j'ai du mal à voir l'intérêt d'un validateur séparé alors que toutes tes infos de validation (ou presque) sont comprises dans le form. Etends un peu l'interface du form et des éléments de formulaires et fait des formulaires autovalidants

Bon moi j'en suis là, ma classe s'utilise pour l'instant comme ça :

$validator = new MFW_Validator();
$validator
    ->regle('user', 'texte')->normalise()->min(4)->max(255)->regexp('/^[a-z][A-Z0-9]$/D')
    ->regle('age', 'entier')->min(18)
    ->regle('pass', 'texte')->min(6)
    ->regle('sexe', 'choix')->valeurs(array('M' => 'Masculin', 'F' => 'Féminim', 'I' => 'Inconnu'));
 
$data = array(
    'user' => "  pouet\n45",
    'age' => '56',
    'pass' => 'tagadapouet');
 
$ok = $validator->valide($data);

 
Les données sont vérifiées et normalisées s'il le faut. Genre dans mon cas je retrouve mon $data comme ça :

$data = array(
    'user' => 'pouet45',
    'age'  => 56,
    'pass' => 'tagadapouet');

 
Les champs textes peuvent donc être trimés, les retours chariots sont supprimés (si champ sur une ligne), et les caractères de contrôles style \x00-\x1f virés aussi. Les champs "entier" sont castés en int.
 
 
Pour les fonctions min et max, elles dépendent du contexte. Soit elles concernent la longueur, soit les valeurs min et max si entier. Comme l'a dit mask, faut que je différencie les deux (on pourrait avoir un champ entier avec un nombre d'une longueur minimum), et rajouter un truc style between en raccourci. Pour l'instant j'en ai pas besoin.
 
 
Pour les champs requis et tout : les champs sont tous requis par défaut (sauf les champs "ouiNon", j'y reviens après). Pour marquer un champ facultatif :

$validator->regle('nom', 'texte')->facultatif()

 
Maintenant si dans un formulaire on a plus de champs facultatifs que de champs requis, on peut faire :

$validator
    ->champsFacultatifs()
    ->regle('nom', 'texte')->requis()

 
Ainsi, suivant le cas, on se fait pas chier à mettre soit 10 000 requis, soit 10 000 facultatifs. On choisi le comportement par défaut.
 
 
Enfin, les champs "ouiNon" (matérialisés par des checkbox). Si on met explicitement un requis(), alors la checkbox doit être checkée pour être valide. Ca sert genre pour les checkbox "j'accepte les conditions d'utilisations" :

$validator
    ->regle('accept', 'ouiNon')->valeur('1')->requis();

 
Comme vous pouvez le voir, j'ai une fonction 'valeur' pour fixer la valeur d'une checkbox, qui sera vérifiée. Pour plein de champs (checkbox, select, hidden), la valeur transmise est vérifiée, on peut pas transmettre n'importe quoi...
 
 
Là sinon le plus gros problème, c'est le côté "God class", les fonctions de validations des différents types implémentés sont toutes dans la classe MFW_Validator. Je séparerais en objets plus tard, pour l'instant j'ai pas trop le budget "temps d'exécution" pour rajouter encore 20 000 fichiers. Lorsque j'aurais installé un opcode-cache sur le serveur de prod, je ferais un gros refactoring de tout ça, avec mes tests unitaires je pourrai faire ça tranquille.

Pourquoi en plus de faire du php tu mixes l'anglais et le français

+1

'ai un mix de français et anglais un peut partout, alors j'essaye de tout migrer en français. Les noms des controller, des paramètres, de toutes les fonctions métier sont en français, alors...

Ca je suis pour Moi je fais tout en français pour des raisons simples: ras le cul de rien comprendre aux méli mélos d'anglais. Et faire de l'anglais pour faire de l'anglais ou paraitre bien ou in... Enfin je suis français et fier de ma langue donc je passerais pas sous le bureau ni de Bush ni de la reine, donc...
 
 
C'est pas évident de faire du tout français, y'a toujours une coquille qui traine par habitude d'appeler un truc comme le veulent les conventions
 
C'est pas pire que l'inverse: faire de l'anglais "parce qu'il faut, qu'on a pas le choix..." et lâcher un mot de français parce qu'on trouve pas d'équivalent correct

Et t'as jamais songé à apprendre l'anglais?

Perso je fais de l'anglais parce que c'est la langue officielle de l'informatique. Point barre, fin de la discussion.

Surtout quand les langages de prog sont en grande majorité basés sur l'anglais.

Quand un mec écrit du Français smsisé je lui pourri la vie, j'aime surement autant la langue française que toi, mais la prog en français, comme dire :

• Si tu veux des références, livres, doc, tuto, la majorité du temps tu trouveras rien de convaicant dans une autre langue que l'anglais
• Quand je code, j'écris mes messages de commit en anglais, je documente en anglais, les noms de function, propriétés, sont en anglais, c'est un tout. Pourquoi? Si un jour je dois bosser avec des étrangers (méttons des polonais, ça va m'arriver dans peu de temps), ils seront surement plus à même de comprendre de l'anglais que du français.
• 99% des langages sont en anglais, de même pour les frameworks, quand je m'appuies sur le nom d'une méthode pour en écrire une autre, c'est surtout pour garder une cohérence entre le langage/framework et mon code.
• Vas donc coder un truc en français et espérer interesser des gens autres que les pecnos de ton village  , le but c'est pas d'être hype, je rappelle que le code doit en partie se documenter tout seul, donc à part des français tu vas pas toucher grand monde avec ta méthode recupererTableau()

Le tout noyé entre des if et autres foreach

• Ne pas avoir la moindre notion en Anglais et programmer ne me semble pas être compatible
• Y'a des trucs qui se traduisement pas, yield, let, fetch,asset...

Edit :

 
Le plus mieux, c'est les noms de méthodes/champs se terminant en "ée". Évidemment, ça passe pas dans la moitié des langages (je suis gentil ), et ça se termine en méthode/champ se terminant en "ee", ça perd tout son sens, ça veut rien dire, ça ressemble à rien, et ça fait chier pour relire
 
Donc +1 pour l'anglais

Règle #1 : Si tu trouves pas la traduction qui va bien en anglais, c'est un problème de modélisation de ton programme

Nan pas point barre Moi on m'a demandé que certains trucs (genre paramètres de controllers) soient en français. Pareil pour les champs en base de données... Alors pour certains trucs j'ai pas trop le choix

 
Ce n'est pas parce que ce n'est pas toi qui en a décidé ainsi que ça en est moins con

 
Ca suffit maintenant. On a déjà débattu de ça y'a longtemps. Si y'en a qui veulent coder en français, ils codent en français et pis voilà. Y'a un moment, faut arrêter aussi.

Bon, revenons à ce qui nous intéresse. Si vous voulez faire un vrai débat sur la langue à utiliser, faites un topic.
 
Il reste le problème, pour les fonctions de validations, des messages d'erreurs
 
J'aimerais bien pouvoir les customiser s'il le faut, genre :

$validator
  ->regle('nom', 'texte')->min(5, 'Vous devez entrer un nom d\'au moins 5 caractères');

 
J'ai pas trop envie d'avoir des machins génériques style 'Le champ "Nom" doit comporter 5 caractères au moins.'
 
Z'en pensez quoi ?

$validator
  ->regle('nom', 'texte')->min(5, 'Vous devez entrer un nom d\'au moins 5 caractères');

 
Que ça va vite te faire chier de systématiquement devoir les saisir à la création de ton objet.
Donc qu'il vaut mieux que tu permettes par défaut de générer ce genre de trucs quand même.

Ouais, je pensais m'orienté vers un message automatique de base, on refile l'intitulé, et on peut customiser s'il le faut :

$validator->
  regle('username', 'texte', 'Identifiant')->min(4)
  regle('pass', 'texte')->min(6, 'Le mot de passe est trop petit, pas bien');

Bon bah feu.

Ah et j'ai aussi rajouter la possibilité d'appeller un callback pour valider en plus, genre on peut faire :

class user_model extends model
{
 
  public function getValidator()
  {
     $validator = new MFW_Validator();
     return $validator
       ->regle('nom', 'texte')->min(4)->max(255)
       ->regle('pass', 'texte')->min(6)
       ->callback($this, 'validation');
  }
 
 
   public function validation(&$data)
   {
        $errors = array();
        if(mysql_num_rows(mysql_query('SELECT * FROM `user`.......')) {
          $errors[] = 'Le nom est déjà utilisé';
        }
 
         return $errors;
   }
}

$validator->
  regle('username', 'texte', 'Identifiant')->min(4)
  regle('pass', 'texte')->min(6, 'Le mot de passe est trop petit, pas bien');

class user_model extends model
{
 
  public function getValidator()
  {
     $validator = new MFW_Validator();
     return $validator
       ->regle('nom', 'texte')->min(4)->max(255)
       ->regle('pass', 'texte')->min(6)
       ->callback($this, 'validation');
  }
 
 
   public function validation(&$data)
   {
        $errors = array();
        if(mysql_num_rows(mysql_query('SELECT * FROM `user`.......')) {
          $errors[] = 'Le nom est déjà utilisé';
        }
 
         return $errors;
   }
}

  You miss a quote, wait, you just edit you bitch

Sinon, perso il me semble que j'avais géré une partie coté vue avec des helpers qui géraient les types de champs, le reste était fait coté controlleur. Et y'avais une liaison directe qui permettait de mettre facilement en surbrillance les champs érronés

$validator
  ->regle('nom', 'texte')->min(5, 'Vous devez entrer un nom d\'au moins 5 caractères');

Stripes utilise un système de fichier Resources configurable (avec des placeholders) pas trop mal fait. Il tente de trouver un message d'erreur dans le fichier avec comme clé (dans cet ordre):
 

• <actionPath>.<fieldName>.<errorName>
• <actionPath>.<fieldName>.errorMessage
• <fieldName>.errorMessage
• <actionPath>.<errorName>
• <defaultScope>.<errorName>

Donc il y a un jeu de message par défaut en <defaultScope>.<errorName> (la scope étant converter pour une erreur de conversion ou validation pour une erreur de validation):

validation.required.valueNotPresent={0} is a required field
validation.minlength.valueTooShort={0} must be at least {2} characters long
validation.maxlength.valueTooLong={0} must be no more than {2} characters long
validation.minvalue.valueBelowMinimum=The minimum allowed value for {0} is {2}
validation.maxvalue.valueAboveMaximum=The maximum allowed value for {0} is {2}
validation.mask.valueDoesNotMatch=<em>{1}</em> is not a valid {0}
validation.expression.valueFailedExpression=The value supplied ({1}) for field {0} is invalid

 
mais rien ne t'empêche de spécialiser une validation précise ou un ensemble de validations (tous les champs d'un formulaire) avec un truc du style:
 

/add.action.value.valueNotPresent = You need to provide something to add

qui est un exemple du cas 1, et va écraser le message par défaut numéro 1 sur le champ "value" de l'action "/add.action".

Ca, c'est la faute aux développeurs tiers (donc en partie notre faute à nous qui somme sur ce forum). Le syndrome typique du "je fais en anglais par ce qu'il n'y a pas de bonne doc dans telle langue mais je corrige ni traduit rien pour les suivants".
Moi, ça me fait rire ceux qui critiquent la qualité des traductions de documentation d'un langage mais qui n'envoient aucun correctif. Si chaque (très?) bon développeur francophone avait envoyé un correctif de traduction on aurait de bien meilleures documentations qu'actuellement. Mais bon, c'est une logique qui a l'air de dépasser la compréhension de la majorité des gens.
 

Et dis moi, combien de chance y a t'il que tu bosses avec des francophones? A par si tu vis dans un pays où les francophones sont minoritaires ou que tu ne bosses qu'avec des correspondants étrangers, il y a plus de chance que tes collègues maitrisent mieux le français que l'anglais, alors pourquoi ne pas faire de double documentation anglais/français? Ca aussi c'est un truc que je trouve hallucinant, cette habitude de ne documenter qu'en anglais par ce que la majorité des documentations importantes sont en anglais (d'une certaine manière, c'est une forme de feignantise qui se comprend vu que la documentation est une étape rébarbative).
Attention, je ne dis pas qu'il ne faut pas documenter en anglais mais que de ne jamais documenter ses créations dans sa langue maternelle est une mauvaise habitude qui n'arrangera rien à la situation.
 

Il n'a jamais dit qu'il ne pigeait rien à l'anglais mais qu'il ne trouve pas toujours le terme anglais approprié. Il y a quand même une grosse marge entre "ne rien connaitre" et "maitriser sur le bout des doigts".

Pour le reste de tes arguments je suis d'accord avec toi.

Ah voilà, c'est exactement ce qu'il me faut Pour l'instant, je vais hard-coder les messages, et dès que j'aurais besoin de faire un site multi-langue, je me tournerai vers ce genre ce gestion de gestion de ressources.

http://www.wordreference.com/

T'as rien de mieux à foutre que de traduire une quinzaine de bouquins de 600 pages chacun et des sites complets?

Parce que je dois avouer que moi si.

Aucune idée, perso je ne cherche même pas dans les docs francophones, je préfère contribuer à la communauté globale dont le langage de facto est l'anglais pour quasiment n'importe quel langage.

Bien meilleures, peut être; toujours merdiques et dépassées, sûrement.

Le faire est surtout une perte de temps sans intérêt à court terme (il faut se taper la doc en deux langues, donc on passe nécessairement moins de temps sur chaque doc qu'on en aurait passé sur une doc unique, donc baisse de qualité globale) et encore plus à long terme (toute modification d'une doc doit être répercutée sur les autres, les contribs externes à l'une des docs doivent être portées à toutes les autres). Ca a un intérêt pour de gros projets quand on peut offloader la doc à des traducteurs/maintainers dont le rôle est de garder les différentes traductions en sync avec la doc "maîtresse", sûrement pas sur de petits projets ou quand on a peu de monde.

Pareil. Et quand le site de PHP me dirige vers la version française, je rebascule sur l'anglaise...

Très bon exemple de doc traduite à l'intérêt plus que limité d'ailleurs: la traduction est parfois limite (voir mauvaise), et sur les versions localisées de la doc il n'y a quasiment pas de commentaires qui font 90% de l'intérêt de la doc PHP online.

Voilà, heureusement qu'il y a les commentaires, la qualité de la doc laisse énormément à désirer. Y'a plein de fonctions à peine/mal documentées .
 
En même temps, quand on connaît le niveau moyen des devs php, laisser la possibilité de mettre des commentaires est en même temps catastrophique, quand on voit le nombre de conneries qu'il y a, et personne pour nettoyer...

+1
Le bouquin qui est sorti à propos de symfony ils l'ont sorti en anglais en première version (alors qu'à la base c'est français comme framework) c'est pas pour rien. Tu touches bcp + de gens à faire ça en anglais.

Perso je cherche pas de doc en français, donc je peux même pas me dire, "à tiens, c'est faux"    
 

Je bosse sur Renault, afaik c'est français, mais la majorité des pays pour nous travaillons sera anglophonne. On a des filiales un peu partout dans le monde -uk,it,es,chn,usa- donc si mon code doit servir dans l'agence, je pense que la langue la plus appropriée sera l'anglais.
 
J'ai pas envie de prendre le problème à l'envers, ni de vouloir faire mon revolutionnaire à deux balles.  

Ouais mais la non, c'est un exemple extrème 50% du temps il manque 90% des infos sur la vf

Es-tu le seul être humain capable d'en traduire des morceaux? J'ai parlé d'envoyer un correctif chacun, pas de traduire tout seul l'intégralité du www.
 

Pourquoi ça? C'est pas par ce qu'il y a beaucoup à faire qu'il faut tout laisser tomber dès le départ. C'est sur que si les neuf dixième des francophones font comme toi et ne s'occupent que de la version anglaise, la version française restera dépassé. Mais d'un autre côté, rare sont les logiciels qui évoluent tellement vite (et violemment) qu'il est impossible de traduire les modifications de la doc aussi vite que nécessaire s'il y a suffisamment de monde près à y sacrifier quelques heures.
 

C'est vrai qu'il faut plus de temps pour maintenir deux versions qu'une seule. D'un autre côté, si on doit en faire une seule pourquoi ne pas utiliser sa langue maternelle? Si on cherche à éviter tout ce qui est contre productif, alors la production d'une version anglaise est à éviter tant qu'on en a pas besoin vu qu'on mettra plus de temps à l'écrire et la maintenir qu'une version écrite dans sa langue natale. (PS : Pour moi l'escuse du "oui mais on sait jamais peut être que plus tard ..." n'est qu'une escuse. )
 
Pour le cas de Shinuza, là, c'est sur que la version anglaise est obligatoire vu que c'est surement la langue la plus parlé par ceux qui sont susceptible de la lire. Je trouve juste dommage de ne pas avoir de version française de la doc à côté.
 
Au fait Shinuza, Renault ils ont des locaux au Québec ou pas? S'ils en ont là bas alors ton attitude est contre productive pour ta société vu que de toute manière ils seront obligé tôt ou tard de faire une version française de ta documentation (les lois du Québec obligent les sociétés à traduire en français tous les documents, documentations à usage interne comprises, qu'ils produisent et qui est utilisé dans cette province) ce qui se fera par le biès d'un logiciel de traduction (avec une doc toute pourri à la clé) ou par le travail d'un autre salarié (qui mettra plus de temps que toi à faire une traduction correcte)

C'est Boulet-Land ici, vous passez votre temps à vous taper dessus

Et pour une fois qu'il y a débat sur le topic, celui-ci ne concerne même pas MVC... dommage !

 
Non mais, de toute façon, j'ai pas que ça, à foutre
 
J'ai déja limite le temps de documenter les projets sur lesquels je travaille alors je vois pas ou tu veux que je trouve le temps de documenter deux fois

Ouais, mon topic J'ai essayé d'arrêter tout ça, mais nan . Si tu veux, tu peux continuer à discuter de validation de données, comment fais-tu dans tes applications ?

Pour chacune des traductions, il faut un projet complet, donc soit tu le fais seul, soit tu dois organiser un projet de traduction... après en avoir demandé et obtenu le droit auprès des auteurs originaux

1. Parce qu'une traduction n'est jamais parfaite
2. Parce qu'il faut penser à tracker, lire, comprendre, traduire et replacer dans le contexte de la traduction chaque modif
3. Tu nous parlais de la traduction de ressources en ligne là (on va oublier les bouquins un instant), tu trouves vraiment que ça ne bouge pas?
4. Parce que les gens ayant les capacités pour faire la traduction (connaissance suffisante des deux langages) n'ont ni le temps ni l'envie de s'emmerder avec ça.

 
Parce que c'est la langue par défaut et qu'avec une doc en anglais on est assuré que ça sera accessible à à peu près tout le monde, alors que dans sa langue maternelle, pas vraiment stu veux
 
Si Torvalds avait écrit Linux en finlandais, je doute que le projet en serait là où il est arrivé      

T'es un peu con comme garçon.

 
Tu veux dire, ça serait prêt pour le desktop ?

 
Alors,... c'est pas forcément tip top, j'ai une classe Form, gérant une collection d'object Input. Le Form gère tout seul la récupération des données et les erreurs pour les champs requis ($form->setRequiredFields(...), $form->getMissingFields(), etc).
 
Pour se replacer dans le contexte MVC, le formulaire est créé et validé par le Model (puis récupéré pour la View pour affichage). Pour les validations spécifiques, je fais un test pour savoir si le formulaire a été envoyé ($form->sent()) ; le cas échant je fais mes validations champ par champ à coup de if, en envoyant les erreurs au formulaire  : $form->error($msg, [$field]).  
 
Là où je trouve pas ça forcément génial par rapport à MVC, c'est que les données sont récupérées directement par l'objet Form et non par le Controller. En même temps cela évite de se taper les récupération de données pour chaque formulaire.

Et toi, avec le français t'en es où? Où ai je dis que je ne comprenais rien à l'anglais? Je le lis largement courement pour une doc, là n'est pas le soucis

Je suis d'accord que c'est la langue majoritaire, je trouve dommage que ça soit une excuse pour faire du tout anglais pour le principe ou par pseudo convention unilatérale
 
Si tu bosses pour un francophone, avec des partenaires francophones, pour un usage purement francophone, je vois pas bien l'intéret de partir sur de l'anglophone pour le plaisir de pénaliser tout le monde dans la compréhension globale et instantané d'éventuels intervenants qui seraient limite en anglais  
 

Il dit qu'il voit pas le rapport... Que le langage soit dans une langue empêche de donner des nom de fonction dans une autre? De faire des commentaires dans une autre langue?
 
Me sors pas l'universalité, mais, pourquoi choisir une langue plutot qu'une autre? Pourquoi toujours les mêmes doivent faire l'effort de comprendre et pas l'inverse? C'est pas comme si le français était aussi peu maitrisé que le polonais...
 
 
Enfin peut importe, mais c'est dommage pour la francophonie votre comportement assez sectaire ou soumis, au choix