... c'est bien ce que je disais ^^

Ne cherche pas à savoir s'il est rempli ou non, cherche tout de suite à savoir s'il contient les valeurs attendues, ca t'évitera les pbs comme ca : "je teste si la var est empty puis si elle est différente de zéro car zéro".

Après plus de souci. Et pour "Ca évite de se retaper les if(empty()) de chaque champs...", rien ne t'empêche de faire un fonction de test, avec les param Min et Max, et hop !

LE problème de vérification des formulaires, c'est qu'il ne peut pas être automatisé avec seulement un test ISSET, car rapidement il est SET (d'autant si tu testes les valeurs retour et que tu ré-affiches dans les champs les valeurs envoyées, même les fausses avec un message d'erreur à l'utilisateur...).

Le test doit être fait sur la valeur, qui elle est 'unique' pour chaque champ puisqu'elle doit être ET significative ET stockable (en BdD)...

C'est donc un ISSET + TESTS aux limites (a minima sur TRIM($_post['monchamp']) pour éviter les malins qui mettent des espaces...) qui eux restent propriétaire de l'application.


Explication par l'exemple :
- les enfants de malalan, c'est >-1 et <10 (de 0 à 9) (et 9 c'est vraiment beaucoup, mais aux limites, ca existe...)
- un titre, c'est inférieur au MAX de bdD, mais pour être significatif tu peux vouloir lui imposer un mini, donc c'est >5 et inférieur à 126 (max BdD =125)
- un choix de liste déroulant (0= sélectionnez), c'est >0 et <(X+1) (le dernier choix !).
- un texte libre (area) comme le titre, mais avec un signifiant plus important (>10...)


Bref, les vérif de formulaire ca me fait rire, car c'est forcément un truc perso qui colle à l'appli, donc aux spécif, donc au 'métier' pour laquelle (et lesquels) elle a (et ils ont) été réalisé.

CE N'EST PAS GENERALISABLE !


Maintenant tu peux appliquer 2 politiques :
- l'exploitant / chercheur : mieux vaut ne rien avoir en bdd qu'une info non-exploitable !
- commerciale : on prends tout et les exploitants se démerderont...

Les tests et les variables obligatoires pour enregistrement seront fait en conséquence, bref, selon l'appli, les spéc, la demande, le métier, la demande initiale qui fait que tu réalises un formulaire , koi ^^

J'ai mis en ligne le source, et l'explication d'usage de Julian75 (en virant les "$mesdonnees" pour utiliser mon array, et l'erreur devient :

Missing argument 1 for MakeCsv::MakeCsv(), called in /../fichier.php on line 63 and defined in /../fonction/export.class.php on line 41

Fatal error: Can't open monfichier.csv in /../fonction/export.class.php on line 51

D'où 2 questions liées ?
- l'argument manquant c'est le fichier ?
- pourquoi le fichier ne s'ouvre pas? Question de droit + répertoire ? Il faut le créer au préalable ? (beurk j'aime pas la gestion de 'file')

Sinon...

"Ah si, on a la liberté d'utiliser des attributs html dépréciés depuis belle lurette, ..."
  Je code si vieux que ca ?

"... et un javascript particulièrement invasif"
J'insite, mais vu que ce code est adaptable, on peut virer l'intrus sans souci, non ?

Peut-être me suis mal expliqué...

- Mon source propose en effet seulement  3 fonctions (les plus courantes d'utilisation ; radio button, textarea et text) qui permettent via les paramètres de se créer comme je leur demande avec un JS d'aide sur onmouseover dans mon cas (addslashe, étant pour le passage des  " ' "  via php qui fusil l'affichage dans le JS (j'aime pas JS) ; dans le doute je le rajoute (ce qui est utile si le message d'aide vient d'une BdD)).
- Le php NE GENERE PAS de TD (sauf si on choisi ce format d'affichage pour les RB). Par contre, j'ai choisi dans mon HTML de mettre mon formulaire en TD...
- Le code ne génère pas de formulaire, en effet.
Par contre l'architecture exposée permet de générer 4 formats de formulaire (en fait 3 formats : vierge, contrôle des saisies, modification, et la page de fiche d'iinfo issu du formulaire.
- en effet c'est PHP + MySQL, donc a adapter avec d'autre BdD....
- IF, ELSEIF, ELSE...
Je suis sur d'une chose et seulement de celle-là, c'est ce que je dois recevoir. Je ne peux rein contrôler d'autre. Donc, afin d'éviter les plantages ou les affichages abscons en recevant autre chose, je teste effectivement les IF et ELSIF des possibles, et met un ELSE pour tous les autres cas.
Je suis donc certain de n'afficher mes infos UNIQUEMENT pour les valeurs attendues des variables contrôlées par ce type de boucle. Bref si un malin s'amuse à me balancer une valeur 'idiote (45 par exemple), il sera traité par le ELSE... Et y'en a des malins ^^
- Comme je disais, je ne donne RIEN concernant les contrôles des données vers la  BdD, ni concernant le création de la requête, cela pour ne pas être trop restrictif... Et on me traite de laxiste du coup ^^
Et en effet, si on utilise autre chose que MySQL, on refait ces requêtes (et gare aux stripslashes), CQFD !


Bref, j'ai fais un code ouvert au possible en virant les trucs PROPRIETAIRE de BdD sauf les stripslashes  (les addslashes gèrent du PHP HTML JS dans ce cas).
J'ai donné un exemple en découpant 1 à 1 les points principales de construction de la page :
- Contrôle des valeurs GET ou POST d'une autre page ou de la même.
- Gestion du <form></form> et des Boutons d'envoie du formulaire
- exemple d'utilisation de chacune des fonctions (dans un formulaire mis en TABLEAU, et alors, si j'aime ca ?)
Je fournis SEULEMENT une architecture des possibles d'utilisation afin qu'à un formualire soit lié 1 et 1 seule page qui gère de plus le format d'affichage différent selon qu'on attende 1 page formulaire ou une page fiche-de-formulaire.

Bref un truc SIMPLE, pas PERILLEUX pour 2 sous, ADAPTABLE, parce que son concepteur à imaginé un truc ultra basique...


Et on me pouille sur des TABLE et des TD !
Sur le fait que je sois telle ou telle BdD...

Soit je n'ais pas compris le concept du réutilsable dans le LIBRE, car adaptable facilement,
Soit PHPCS attend des bouts de codes complets mais restrcitifs car attachés à une problématique fonctionnelement précise et particulièrement individuelle, donc inexploitable par un tiers,
Soit vous n'étiez pas réveillé en lisant ce code,
soit il est trop complexe pour le commun des mortels et je suis un génie (Yes !!!!!!!!)..


Bref, je me trouve bien marie de vouloir aider en publiant du code qui ne vaut pas tripettes, certes, mais dons l'utilisation vaut son pesant d'or (m'est avis que...)

Faudra m'expliquer quelque trucs là...

Tartuffe plus endormi, quoique...

Teclis,
1/ si t'as pas compris, je ne peux pas t'aider.
2/ c'est pas 1 minute par champs, c'est 452,41 minutes !
3/ si tu ne veux pas de tableau, tu n'en fais pas. Le PHP ne génère aucun tableau.
4/ 1 formulaire c'est simple ; 4 versions d'un même formulaire sur le même page, c'est plus compliqué.

J'en doute fort ! Des preuves ?

Non, rien que des on-dits qu'on m'a toujours dit...
Et répetés !
Et re-re-dit..

Alors, je crois, puis j'applique !

Les vacances sont courtes ^^
Donc j'ai ajouté un test avec les minetype.. MAIS :
1- pour m'abstraire des paramètres de l'hébergeur et de la mise à jour de son fichier de gestion des Minetype, rien de 'magic', mais un array des Minetype possibles.
2- cela doit certainement dépendre du navigateur, mais il y a une différence entre 'appli/msword' et 'appli/vnd.ms-word', donc on double les Minetype possibles.
3- en transformant un ".exe" en ".xls", je suis passé sans problème. Donc la sécurité dû au Minetype pour éviter les fichiers truqués, je n'en suis pas convaincu.
4- les fichier '.TXT' apparaissent en 'appli/download', donc plus de '.TXT' autorisé en upload...

Comment faire plus de sécurité ?
De la sécurité Utile ?

Je suis tout ouie !

- le seul test qui se rapproche d'un "isset" est la : if (is_uploaded_file($pnomtmp)... Cependant il est aussi là strlen($_FILES['p_coll_draft']['name'])>4.
En fait peut m'importe qu'il soit isset ou non. Car travailler avec un nom de fichier comme  "2.k" ne m'intéresse pas. Par contre travailler avec un fichier dont le nom possède un longueur minimal (5) me semble important.
La logique en la matière est :
1/ ais-je un nom de plus de 4 caractères de long
2/ est-il monté en mémoire un un nom de longueur 'correct'
3/ sa taille
4/ son extension
5/ son stockage
En fait je préfère effectuer les tests les 1 après les autres en avançant un peu à chaque étape, plutot que de faire un gros test unique. Cela me permet de dissocier les messages d'erreur pour les utilisateurs.
Par contre, quel est l'impact en terme de perf de ce choix d'algo ? Ca, je n'en sais rien !
- $il_existe_deja_un_fichier_en_bdd_pour_l_utilisateur : cette variable à un nom à coucher dehors avec un billet de logement, pour que tous les quidam comprennent de koi il s'agit. Ma vrai variable est ($old_plak) ^^
- en php, et uniquement en php, $testoki=$testoki+1 est plus rapide que $testoki++ (est-ce encore valable en php 5 ?)
- Cette fonction est décpréciée depuis PHP 4.0.6. N'utilisez pas cette fonction. Utilisez mysql_select_db() et mysql_query() à la place. : je fais du copier/coller depuis php 4.0.6 ^^ Je me mets à jour. Merci ^^
- Minetype et fichier 'trucké"... Effectivement, je me posais la question du moyen de vérification du type réel. Je m'en vais donc voir ce qui ressort de l'usage de "mime_content_type ( string filename )" lors du truckage d'extension...
Et je mettrais à jour (après les vacances...)
- pour le debug... En effet d'accord. Mais à l'usage je code sans debug, et lorsque ca ne fonctionne pas, je positionne les debug un à un. Lorsque ca fonctionne je les '//' tous [: -))....

Merci des commentaires

...pour la déesse du code...
- Pas beaucoup d'HTML dans ce code...
- Type de fichier, 2 solutions, j'en ai pris une, je l'assume...
- Array, je peux difficillement le faire plus simple

Bref, ce qui est grave c'est la critique gratuite et auto-justifiée par des phrases qui laissent penser qu'on est un expert qui ne se donne même pas la peine d'expliquer tellement l'autre est nul de n'avoir pas compris des choses si simple...

Que dire ? Et bien dit le !
Au moins tous le monde profitera de ton expertise qui améliorera le code.