EXTRACTEUR DE VARIABLES DE FORMULAIRES
neigedhiver
Messages postés
2480
Date d'inscription
jeudi 30 novembre 2006
Statut
Membre
Dernière intervention
14 janvier 2011
-
23 avril 2008 à 15:08
FhX Messages postés 2350 Date d'inscription mercredi 13 octobre 2004 Statut Membre Dernière intervention 18 avril 2015 - 10 mai 2008 à 18:41
FhX Messages postés 2350 Date d'inscription mercredi 13 octobre 2004 Statut Membre Dernière intervention 18 avril 2015 - 10 mai 2008 à 18:41
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/46434-extracteur-de-variables-de-formulaires
https://codes-sources.commentcamarche.net/source/46434-extracteur-de-variables-de-formulaires
10 mai 2008 à 18:41
7 mai 2008 à 21:46
7 mai 2008 à 19:10
*me => []
7 mai 2008 à 19:00
Donc faut nous excuser aussi si on s'emporte pour 3 fois rien quelques fois ;)
7 mai 2008 à 14:31
Il est clair qu'entreprise et Open Source n'ont pas les memes objectifs... T'as des entreprises qui jouent leur reputation donc qui font du code serieux, mais c'est toujours pour repondre a un marche qu'elles developpent...
Apres, t'as des entreprises qui font de l'open source, et qui savent tres bien mixer les deux (Zend par exemple, qui fait un code porc pour php, car de toute facon, ils sont les seuls a maintennir ce logiciel, mais ils font des choses correctes, et attirantes pour les plugins pour php, histoire d'attirer les contribution.)
7 mai 2008 à 08:30
c'est vrai que je me suis un peu emporté.
du coté de la table sql, le code ne la créé pas directement, il l'affiche simplement, après un copier coller pour la reprendre et la modifié reste faisable.
Cette partie du code n'est pas indispensable, je l'ai laissé car elle m'était utile à moi.
------------------------------------------------
Sinon rien d'initié dans ce script(snippet),
et si cet input est dans un commentaire html ?
je crois que DOMDocument est plus approprié...
------------------------------------------------
Si tant est que le HTMl soit un bon XHTML, sinon il faut d'abord parser et c'est chiant (je sais, je l'ai fait souvent lol). Mais en effet, j'y avais pensé en voyant ce code.
------------------------------------------------
là, j'ai rien pigé part "Sinon rien d'initié dans ce script", j'ai mis initié a cause de la regex, car je trouve que pour un débutant PHP, les Regex restent flou a comprendre du premier coup.
J'en profite pour faire du même coup une grosse modification du code...
7 mai 2008 à 04:40
"et perso je n'aime pas travailler avec les $_POST pour diverse raison:
echo "salut $_POST['nom']"; => j'ai du mal"
C'est pas parce qu'on a "du mal" qu'il ne faut pas savoir s'adapter. Si $_POST[] existe, c'est pas pour rien. Je comprendrais jamais ce manque de suivi de l'évolution d'un langage. C'est pas parce qu'on connait les bases qu'il faut s'arrêter la. Mais bon, nous avons 2 conceptions différentes de la chose...
Maintenant, je le vois bien que c'est du code rapide. Je m'en suis aperçu dès le début. Suffit de voir l'utilisation de variables non déclarées ou autres genre de petits trucs qui m'ont mis la puce à l'oreille dès le début.
Tu fais ce que tu veux de ce que je viens de te dire plus haut. Les quelques conseils disséminés dans mes posts ne sont pas la que pour cracher sur ton code, ils sont la surtout pour te permettre d'évoluer dans le langage qu'est le PHP. Libre à toi d'interpréter mes posts comme tu le sembleras mais je m'en tiens à mon expérience et je ne peux pas revenir sur mes déclarations.
Après, entreprise/open source, y'a limite un petit foutage de gueule :) C'est pas parce qu'on est en entreprise qu'on n'a pas le droit d'être rigoureux sur du code. C'est ce que je te fais remarquer et il ne faut pas prendre cela pour une attaque personnelle.
Et pour finir :
"donc passer trois heure a faire ce que ce code faire un trois seconde, la propreté, je m'en balance." Je te dis merci. Oh si, un grand merci ! Car c'est grâce à des gens comme toi que des gens comme moi trouvent du boulot :)
Imagine si tout le monde sortait du code suffisamment propre... le quart voir la moitié des développeurs seraient au chômage :)
Finalement, je t'aime bien !
xD
6 mai 2008 à 23:15
6 mai 2008 à 22:42
et si cet input est dans un commentaire html ?
je crois que DOMDocument est plus approprié...
@+
6 mai 2008 à 22:25
je comprends le point de vue "entreprise"; ceci dit, là, on est sur un site "open source". Et je suis d'accord avec Coucou et FhX : quand on poste un code open source, on fait propre. Je ne pense pas que là-dessus, tu aies raison de rebiffer. Et vu la longueur du code, ça ne te prendrait pas des heures de le réécrire proprement, voire de réfléchir à une autre manière de le faire.
Par contre, contrairement à Coucou, je trouve ta dernière phrase très intéressante et je vais y répondre :
oui, je cracherais dessus...parce rouler dans une 2 chevaux qui aurait un moteur de porsche, ce serait le meilleur moyen de se tuer à coup sûr...il en va exactement de même avec les codes... : un code mal écrit mais très utile...est généralement un code très dangereux.
Je ne pense effectivement pas que FhX aie réellement compris à quoi servait ton code. Je ne lui jette pas la pierre, j'ai eu du mal aussi; et FhX est un excellent codeur PHP, ses conseils sont tjrs avisés (comme bcp ici hein, Coucou, Neige, Yoman, je ne sais plus qui a posté donc désolé pour les autres que jh'ai oublié :-) ).
Ton code présente quand même bcp de lacunes pour être vraiment utiles au plus grand nombre... : la syntaxe de la création de la table ne conviendra pas à toutes les BDD; la table est extrèmement basique à tous les points de vue : impossible d'exploser les champs d'un formulaire sur plusieurs tables, impossible de jouer avec des tables de jointure (un select, typiquement...ça demande svt une table de jointure), impossible de changer les types (une table avec tous les champs en 'text'...boaf...), impossible de créer des clefs étrangères etc. Bref, il n'y a pas que le code en lui-même qui n'est pas optimisé : son résultat ne le sera pas non plus. Ce code crée des tables qui seront très lentes et dont la structure sera très mauvaise, quasiment à tous les coups.
Je suis d'accord : on se fout, dans un tel cas, que le code prenne des heures à s'exécuter ou quelques minutes...mais le résultat, lui, doit être optimisé, sinon quel intérêt ? Se retrouver avec un site très mal structuré et lent ? Je préfère encore passer du temps à me taper à la main le MCD et avoir une vraie structuren, plutôt que de lancer ce code et devoir tout modifier, ce qui sera sans doute plus long.
Et j'aimerais bien avoir ton point de vue là-dessus en tant que salarié d'une entreprise : parce que si l'entreprise n'aime pas que l'on passe trop de temps à développer un truc...elle aime encore moins que le truc développé soit lent, mal optimisé, et ne satisfasse du coup pas les clients.
6 mai 2008 à 21:57
pour la propreté du code, c'est un outils perso, et de plus, je connais pas toutes les finesse du php.
le poster ici me permettait de le faire partager et surtout de savoir si je pouvais l'améliorer, comme c'est le cas
mais le code proposé par FHX bien qu'ayant un résultat approchant ne fonctionna pas du tout de la même manière
6 mai 2008 à 21:51
moi echo 'salut'.$nom; ou echo 'salut'.$_POST['nom']; ca depend du contexte.
c'est justement en entreprise que la propreté est parfois négligée... logiquement, l'open source se doit d'etre propre (par souci de partage, compréhension, et honte devant toute la communauté qui lit ton code.)
la fin de ton commentaire n'est pas appropriee... si pour un petit code tu fais porc, alors pour un gros, on peut s'attendre au pire...
6 mai 2008 à 21:42
-------------------------------------------------------
Comment peut-on encore trouver quelque chose d'aussi exubérante :
# $filtre_radio = $_POST['filtre_radio'];
# $name_page = $_POST['name_page'];
# $requete_sql = $_POST['requete_sql'];
???
-------------------------------------------------------
on s'en fout, c'est pas pour le site.
et perso je n'aime pas travailler avec les $_POST pour diverse raison:
echo "salut $_POST['nom']"; => j'ai du mal
je prefere: echo "salut $nom";
de plus, le code sert lors de la création du site donc faire attention à la rapidité du code n'est pas important
tu trouve le code inutile, je l'aurais pas mis si il l'était réellement.
pour la Regex, il y a eu un correction dans l'un des post précédent donc tu fait un remarque déjà résolu. juste que j'ai pas le temps de mofifier ca maintenant.
ton extracteur simplifié marche sans doute (flemme de testé) mais il ne fonctionne pas de la même manière que le mien, pas du tout.
le tient analyse les post transmis, le mien lit le fichier formulaire à la source
----------------------------------------------------------------
Pour le coup du "puisque que l'extracteur n'est pas prévu pour être utiliser DANS le site, mais lors de la création du site web", je la connais on la sort quand on veut pas se faire chier. Mais un petit bout de code montre la qualité d'un code en entier et c'est la ou j'ai un peu peur.
----------------------------------------------------------------
alors je trouve que tu n'as rien compris ou que tu n'as pas lu les post d'avant.
ce code a pour but de faire gagner du temps (en se moque des quelques millisecondes d'éxécution du code pas propre) car je travaille en entreprise. donc passer trois heure a faire ce que ce code faire un trois seconde, la propreté, je m'en balance.
deuxièmement, un webmatser a beau etre payé a l'heure, s'il met deux jour un faire un outils potable bonjour la perte de temps et de contrats
pour finir, "je la connais on la sort quand on veut pas se faire chier" si tu la connais, tu dois sans doute l'utiliser
re pour finir (j'en tient un couche) "Mais un petit bout de code montre la qualité d'un code en entier et c'est la ou j'ai un peu peur", si on te propose une 2chevaux avec un moteur de porshe, tu crache dessus ?
5 mai 2008 à 20:20
J'ai de gros doutes :o
Pour moi, ce code ne sert à rien sauf à masquer une éventuelle flemme du codeur. Je m'explique :
Comment peut-on encore trouver quelque chose d'aussi exubérante :
# $filtre_radio = $_POST['filtre_radio'];
# $name_page = $_POST['name_page'];
# $requete_sql = $_POST['requete_sql'];
???
Mais à quoi cela sert-il ? A cacher le fait que les données proviennent d'un POST ??
La vrai question que tu devrais te poser n'est pas "comment faire pour me débarasser de ce POST afin d'avoir juste les noms de variables ?" mais plutot "comment exploiter au mieux POST pour éviter de dupliquer mon code ?"
Pourquoi vouloir extraire à tout prix quand tout est déjà créé dans un tableau et qu'on vous a mâché tout le travail ?
Tu peux arriver à la même chose avec POST[] ... :s
Pour le coup du "puisque que l'extracteur n'est pas prévu pour être utiliser DANS le site, mais lors de la création du site web", je la connais on la sort quand on veut pas se faire chier. Mais un petit bout de code montre la qualité d'un code en entier et c'est la ou j'ai un peu peur.
Pas de panique, je ne mange personne, je ne fais qu'exposer mon point de vue.
Ex (sans ton extracteur) {
foreach ( $_POST as $key=>$val ) {
echo $key.' -> '.$val.'
';
}
Pas besoin d'extracteur :)
De plus : $num = preg_match_all( "/name="(.*)"/Us" , $texte, $mots);
Avec ça, tu vas récupérer tous les name="" de chaque balise... sachant que 'presque' toutes mes balises en possèdent, y'a pas un petit problème quelque part ? ;)
5 mai 2008 à 08:57
de plus, ca ne multiplie pas la charge mémoire puisque que l'extracteur n'est pas prévu pour etre utiliser DANS le site, mais lors de la création du site web
4 mai 2008 à 20:27
Alors ton code ne sert strictement à rien. Sauf à multiplié par 2 (environ) la charge mémoire, ce code ne sert à rien du tout.
Pourquoi vouloir se forcer à utiliser $name plutôt que $_POST['name'] ??
Quelque chose doit m'échapper... :s
4 mai 2008 à 10:50
3 mai 2008 à 19:14
Minime :s
Surtout que maintenant, avec les nouveaux éditeurs, il te suffit d'une combinaison de touche pour écrire $_POST[] tout seul :s
Mais bon :o
28 avril 2008 à 19:37
28 avril 2008 à 17:27
<?php
$a=NULL;
echo isset($a)?'isset => oui':'isset => non';
?>
ca renvoie :
isset => non
quand je dis un truc, c'est pas forcement une blague...
quand $a = NULL; alors $a est definie, mais pourtant, isset renvoie false...
28 avril 2008 à 17:18
sinon, je préfère isset, ca laisse un plus grande liberté dans le code qui suit et pour des champs non obligatoire, isset est préférable.
28 avril 2008 à 17:14
28 avril 2008 à 17:13
isset = true
empty = false
!empty = true
28 avril 2008 à 17:11
isset=>false;
empty=>true;
si la variable est define:
isset=>true
empty suivant le contenu de la variable;
28 avril 2008 à 17:10
28 avril 2008 à 17:06
28 avril 2008 à 17:04
28 avril 2008 à 16:53
28 avril 2008 à 16:52
si ta varible est défini, tu auras pour
if(isset($_POST['truc']) && !empty($_POST['truc'])):
if(FALSE && FALSE)
si défini et non nulle:
if(TRUE AND TRUE)
si défini est nulle:
if(TRUE AND FALSE)
(je crois que j'ai tous bon ?!?)
28 avril 2008 à 16:43
empty => le contenu de la variable est vide ou pas,
mais siu tu dois verifier le contenu apres :p enleve le empty !
28 avril 2008 à 16:16
if(isset($_POST['truc'])) est largement suffisant (ou quelque chose m'échappe)
28 avril 2008 à 16:12
on peut ajouter, un if(is_array($item)){ foreach($item as ....., pour contourner ça,
sinon ma solution permet d'ajouter automatiquement des if(isset($_POST['truc']) && !empty($_POST['truc']))
et perso c'est ce que je fais :D
28 avril 2008 à 15:17
28 avril 2008 à 15:01
pour la documentation, je pensais que c'était clair, je ferais mieux la prochaine fois.
28 avril 2008 à 08:52
Après avoir été interessé par le script, puis dans le doute, puis plus du tout, puis lu les commentaires, je pense qu'il peut etre utile, si toutefois j'ai (enfin) compris son role:
(re-) generer _sur sollicitation de l'admin_ la liste des champs attendu d'un formulaire afin de mettre a jour les scripts de traitement, à commencer par la base de données. Dans ce cas, c'est une approche pragmatique d'un problème précis. Ce n'est pas un script de production mais un script d'administration.
Que ce soit ça ou pas, je suggère quand meme de mettre une doc (description) plus parlante la prochaine fois.
28 avril 2008 à 02:45
mais je vais vous presenter ma methode a moi :p
dans l'attribut "action" du formulaire en question je met 'champs.php' , dans 'champ.php' ya :
<?php
foreach($_POST as $item=>$value){
echo '$'.$item.' = '.$value .'
';
}
?>
et je copie/coller le resultat dans mon script :)
25 avril 2008 à 18:35
Et là on ne parle pas d'un "simple" formulaire, mais d'une liaison directe entre un formulaire et une base de données, avec la possibilité d'y stocker les types attendus et tout un tas de choses.
Il faut savoir faire la part des choses entre perdre quelques millièmes de seconde pour lire un fichier XML et avoir un code générique, simplifié, facilement évolutif et portable, et en gagner autant mais faire du spécifique à chaque fois. Parce que faire toutes les vérifications pour chaque formulaire, vérifications personnalisées donc, avec autant de scripts que de formulaires, ce n'est pas forcément préférable à avoir un code générique qui s'appuie sur un flux XML dont la structure est définie et qui décrit ce qui doit être fait. Dans le cadre du développement massif d'applications web, la 2de solution est largement plus performante même sur le court terme.
25 avril 2008 à 13:23
25 avril 2008 à 11:05
Pour le mode requete SQL, peut importe pour moi le type (int, text,...) du champs, car je veux juste les données (pas de calcul). de plus, vu que sur le serveur de l'entreprise je n'ai pas accès à une interface phpmyadmin ou autre, j'ai juste à copier/coller la requete dans un fichier php qui créé la table.
---------------------------------------
MALALAM à dit:
Donc, j'aurais pu utiliser le parsing des fichiers via une expression régulière, MAIS j'aurais fait générer à mon code un fichier XML (par exemple) de description des formulaires.
parce qu'on a fait en sorte que de toute manière, cela fonctionne tout de suite...mais en parvenant à obtenir petit à petit de la qualité
---------------------------------------
je n'utilise pas de XML pour la simple et bonne raison que je ne sais pas à quoi ca sert.
et je suis tout à fait d'accord avec toi pour ta dernière phrase ^^
25 avril 2008 à 08:07
si je suis d'accord avec vous, ça n'est pas tjrs aussi simple.
Prenons l'hypothèse (la seule pour laquelle je vais justifier un peu ce code, en fait, en tous cas une partie de ce code) que ce n'est pas notre formulaire, qu'il y en a d'autres comme ça dans l'applicatif, et que ces formulaires soient tous vraiment gros, que nous soyons au travail, et, étant au travail, que nous ayons vraiment peu de temps (et ça...c'est LA donnée essentielle) : la récupération des noms des champs avec le principe de ce code se justifient. J'ai fait bien plus crade dans le cadre de mon boulot parce que je n'avais pas le temps de faire propre. Le temps c'est de l'argent bla bla : c'est très, très vrai en entreprise. Par contre, ça ne justifie QUE la partie récupération, pas la suite (création de la table etc). Parce que là, ça devient d'une part moins efficace (typage des champs de la BDD très approximatifs...structure de la BDD absolument pas optimisée etc), et d'autre part, on continue dans la même voie que l'applicatif qui n'est pas le notre : on n'ajoute rien pour se faciliter la tâche plus tard. Donc, j'aurais pu utiliser le parsing des fichiers via une expression régulière, MAIS j'aurais fait générer à mon code un fichier XML (par exemple) de description des formulaires. Peut-être aurais-je exploité ce descriptif directement dans un premier temps, mais au moins j'aurais eu ce fichier et je me serais donné l'occasion, le jour où j'aurais eu plus de temps, de retravailler un peu ça.
Parce que même quand on est au travail et que l'on manque cruellement de temps, si on fait gaffe à ce qu'on fait, on peut améliorer une situation dramatique par petites touches, en ne perdant rien en terme de production parce qu'on a fait en sorte que de toute manière, cela fonctionne tout de suite...mais en parvenant à obtenir petit à petit de la qualité.
25 avril 2008 à 03:24
(nan moi je rentre juste d'un bar, et je remarque des petits details amusants )
sinon, dans quasiement tout les cas, tu peux choisir comment tu generes le formulaire (sauf si c'est pas le tien)
Nous distinguerons donc deux approches :
C'est ton formualire
- tu dois gerer tes donnees sout un format plus exploitable que le html brut,
array ou objet, comme tu veux, mais ca c'est franchement porc...
C'est pas ton formulaire
- tu dois parser le xhtml ou utiliser ta preg (que je trouve plutot porc,
mais c'est un detail) pour passer de son code html a un format plus brut,
plus abordable, en un mot : parser son formulaire.
En effet, avec un formulaire sous forme d'array ou d'objet, qu'il soit de toi ou pas, on peut tout faire... Il est exploitable comme on le shouaite, de facon simple, c'est pratiquement toujours une simple boucle, peu importe ce que l'on veut faire...
On veut creer une table ? C'est une simple boucle
On veut inserer dans une table ? C'est une simple boucle
On veut verifier si le formulaire a bien ete poste ? C'est une simple boucle
On veut pre-remplire le formulaire (si il a ete mal poste) ? C'est une simple boucle
On veut afficher le formulaire ? C'est une simple boucle
en clair : utiliser un format HTML brut pour faire ce genre de choses, c'est VRAIMENT une mauvaise solution...
24 avril 2008 à 23:42
Vite fait...
"en théorie, il vaut mieux faire comme le dit neigedhiver, mais dans ce cas précis je ne peusx pas."
Bon... J'suis désolé, j'vais passer pour le gros chieur de service, mais... Si tu postes une source qui ne te sers quasiment qu'à toi dans un cas très précis... je vois pas l'intérêt...
Je ne note toujours pas, toujours pour la même raison...
Allez bonne soirée, moi, j'vais m'coucher. Soirée d'merde.
24 avril 2008 à 21:56
Pourquoi pas.
24 avril 2008 à 21:00
le seul soucis, c'est que c'est tellement énorme, que je ne peux pas (ce n'est réellement pas faisable) faire comme je fais d'habitude, c'est a dire créer la table en premier. le formulaire change tous les deux jours. donc plutôt que de chercher dans ma liste lesquelles ont été supprimé, et lequelles on été rajouté, j'utilise ce script, qui me permet de faire ca en 3 min.
en théorie, il vaut mieux faire comme le dit neigedhiver, mais dans ce cas précis je ne peusx pas.
d'autre part l'extract intervient seulement si la table est déjà en place. et je n'utilise pas $_POST['nom'] directement car ce n'est pas le but du script.
le seul est unique but du script est de retrouver, de manière simple et rapide, TOUS les NAME du formulaire.
24 avril 2008 à 20:59
Cette source va chercher les champs d'un formulaire dans une page html d'après leurs noms (name : c'est de l'anglais) et utiliser ces noms pour récupérer les variables correspondantes dans $_POST.
C'est pas que ça me choque, mais vraiment, j'ai l'impression que c'est prendre le problème à l'envers dans la conception.
24 avril 2008 à 19:08
moi j'attends toujours l'explication : ça apporte quoi par rapport à un simple extract() ?
Mon autre interrogation est : ça sert à quoi de doubler des variables ($nom = $_POST['nom']...pourquoi ne pas utiliser directement $_POST['nom'] plutôt que de faire doubler l'utilisation de la mémoire ?) ?
24 avril 2008 à 16:15
Tu prends le problème à l'envers.
Personnellement, je ne PEUX PAS avoir ton problème, parce que je construit mon formulaire en dernier. C'est d'ailleurs dans l'ordre des choses. Si tu fais l'analyse de ton projet, tu construit ta base avant le formulaire.
Du coup, ton script ne sert qu'à quelqu'un qui met la charrue avant les boeufs.
Par exemple, je suis en train de bosser, à titre perso, sur un (gros) projet de site documentaire et communautaire. J'en suis à l'analyse du projet, c'est à dire que je détaille le fonctionnement de chaque partie du site (forum, articles, etc), je sais déjà quelles sont les informations que je vais stocker. J'en rajoute de temps en temps. Ensuite, je vais faire un MCD et un MLD, puis créer ma base de données. Ensuite seulement, j'aurai les formulaires qui permettront de saisir les données.
Ca, c'est l'ordre normal quand on veut faire les choses bien. De là, je peux faire un fichier avec les champs nécessaires suivant les cas (ce ne sont pas les mêmes lors de l'éditions/création d'un article que lors de sa lecture), le formulaire n'est pas non plus le même pour un modérateur que pour un auteur ou un admin.
Donc oui, je me vois faire un copier/coller des 109 champs dans un fichier texte : parce que je ne le ferai qu'une seule fois. C'est exactement la même chose que le code de mon site : je ne l'écris qu'une fois, mais je vais pas faire un script pour automatiser l'écriture des fichiers... Tu vois ce que je veux dire ?
Ecrire à la main UNE FOIS les noms des 109 champs, c'est dans l'ordre des choses.
Bref, je persiste à être sceptique...
24 avril 2008 à 14:51
array('name'=>'nom_input_1', 'defaultvalue'=>'valeur', 'type'=>'text'),
...
);
tu peux faire un truc du genre sans faire d'objet, ca sera moins souple, mais ca fonctionnera
24 avril 2008 à 14:32
tu te vois faire un copier collé de tes NAME ? toujours regardé ou tu en es pour voir si tu en a loupé.
Avec ce script, tu récupère tout et tu le stock ou tu veux.
24 avril 2008 à 14:28
Tu vas donc chercher un formulaire dans un fichier, que tu parses, en gros.
Ca me parait pas optimisé, mais du coup, ça me parait moins insécurisé que ce que je pensais. Mais pas encore au top.
Je préfère quand même stocker mes champs dans un fichier séparé, quelque soit leur nombre. C'est quand même plus simple de les récupérer dans un array, il suffit de lire le fichier avec file()
Parce que ta source me fait m'interroger sur le genre de cas où l'on peut en avoir besoin...
Dans le cas d'un site web développé correctement, le mode requête est inutile : la base de données est créée bien avant le formulaire, puisqu'elle découle de l'analyse et du MCD et du MLD (cf méthode Merise). Elle ne DOIT PAS découler d'un formulaire.
J'ai donc l'impression que concernant la conception, l'analyse, tu ne fais pas les choses comme il faut.
Bon je comprends peut-être mal ta source, mais ce mode requête, je ne vois pas dans quel cas il pourrait vraiment servir (désolé, j'ai vraiment du mal lol et non, c'est pas de la mauvaise volonté)
Pour ton expression régulière, je te proposerais bien un truc dans ce genre :
$num = preg_match_all('"``Uis' , $texte, $mots);
Bon je sais pas ce que ça vaut, j'ai pas testé parce que j'ai pas ce qu'il faut pour...
24 avril 2008 à 14:28
mais ce script m'est très utile, alors je voulais le faire partager.
Néanmoins, si on peut l'améliorer, ou le remplacer par quelque chose de plus rapide/puissant/pratique, je suis preneur.
24 avril 2008 à 14:25
apres l'avoir declare, je l'utilise comme un element xml normal pour l'afficher
j'ai un $form->hasbeenposted() pour savoir si il a ete rempli, ensuite
$form->isGood() pour savoir si il a ete bien rempli, et enfin, $element->getVal() pour recuperer la valeur d'un element du formulaire...
24 avril 2008 à 14:11
en fait, pour les contenu du formulaire, c'est pareil que toi. sauf que j'ai 109 nom différent alors les notez à chaque fois ç coté c'est long. Là, je ne m'occupe plus de rien, ca sort tout seul.
24 avril 2008 à 14:07
Je continue de penser que je ne vois pas l'utilité de ta source.
Personnellement, pour extraire un formulaire, je préfère stocker les noms des champs que je vais devoir traiter dans un fichier (xml, texte, peu importe) dont je récupère le contenu au moment du traitement du formulaire.
Si mon formulaire est bien fait (ce qui est le cas, me concernant) le fichier en question comprend exactement les champs du formulaire. Je sécurise ainsi le traitement des données.
Par ailleurs, utiliser des variables portant le nom des variables POST ne me parait pas sécurisé... Comme je le disais, ça revient à utiliser extract(), ce qui n'est pas recommandé sur les données dont la source n'est pas fiable ($_POST, $_GET, $COOKIE).
Bref... Je suis pas convaincu... Je ne mettrai donc pas de note pour pas flinguer ta source.
24 avril 2008 à 13:45
ca doit pouvoir se faire
24 avril 2008 à 13:33
24 avril 2008 à 11:41
quant à l'utiliter du script, c'est pour reprendre les gros formulaire.
par exemple, j'ai un formulaire avec 109 champs, radio, checkbox. Pour reprendre tous les nom de champs contenu dans name="" il suffit de lancer une analyse du fichier contenant le formulaire pour récupérer tous les noms de variables. je stocke ensuite cette liste dans un array et elle devient exploitable.
ensuite, sur ma page de traitement de formulaire (CGI ?) il suffit de marcourir l'array avec un foreach:
foreach($array as $nom_var)
{
${$nom_var} = $_POST[$nom_var];
}
ca evite simplement de se taper à la main les 109 $_POST[''].
le mode requete sql est utile si les données soivent etre stockées dans une table, ca sort directement la requete pour créer la table. sans avoir a la faire à la main.
les doublons, c'est pour supprimer les variables en trop quand des radio se suivent
si vous avez d'autres questions, je suis dispo ^^
24 avril 2008 à 11:32
Ce n'est pas ce que j'ai dit. J'ai dit que preg_match_all() retourne un entier qui est le nombre de résultats satisfaisant le masque, et non une chaine de caractères. preg_match_all) ne retourne RIEN D'AUTRE. Elle permet d'assigner les chains capturées à une variable, mais NE LES RETOURNE PAS.
C'est un problème lexical : fais attention à ce que tu dis, mais aussi à ce que je dis... Exprime toi avec exactitude, c'est important dans ce boulot.
Pour file_get_contents() le second paramètre est certes optionnel, mais lui spécifier 'r' équivaut à lui passer le booléen true. Donc oui, ça marche, mais y mettre n'importe quoi n'est pas rigoureux. De plus, qui sait ce que PHP fera de ce second argument à l'avenir ? On doit lui passer un booléen, pas une chaine de caractères.
Bon mais tu continues de faire :
$nb = count($mots[0]);
Alors que preg_match_all RETOURNE DEJA CETTE VALEUR.
C'est ta variable $num.
Cette ligne ne sert donc à rien.
Sinon, j'ai pas compris l'intérêt de ta source... Est-ce que tu pourrais détailler un peu, parce que là, pour moi, elle ne sert à rien, n'apporte rien... Bref, je suis dans le vague.
24 avril 2008 à 10:11
Quand à l'erreur sur file_get_contents(), ça vient d'un copier/coller depuis un fopen, et je n'ai pas rectifier (ça marche quand même). De plus on est pas obligé de mettre un argument après le path.
23 avril 2008 à 15:08
J'ai pas regardé en détails le code, parce que je suis resté bloqué sur deux trucs...
Je pense que tu devrais reprendre la doc pour savoir comment fonctionnent vraiment certaines fonctions, ça t'évitera de leur passer n'importe quoi en argument ou de récupérer n'importe quoi comme résultat.
Par exemple file_get_contents() : le second argument n'est pas 'r' ou que sais-je, c'est une boolean (true ou false) qui indique s'il faut chercher dans le répertoire include_path défini dans la configuration de php.
Pour ce qui est de preg_match_all(), cette fonction retourne non pas un texte, mais un entier qui n'est autre que le nombre de résultats qui satisfont le masque.
Un conseil donc, avant de poster une source : assure toi de bien utiliser les fonctions...