Vous ne trouvez pas de réponse à votre problème ? Alors posez la question dans le forum. Souvenez-vous qu'il n'y a jamais de question bête, mais rester dans l'ignorance parce que l'on n'ose pas poser une question, ça c'est une erreur !

EXTRACTEUR DE VARIABLES DE FORMULAIRES


Information sur la source

Catégorie :Formulaires Classé sous : formulaire, extracteur, variables, extraction, variable Niveau : Initié Date de création : 23/04/2008 Date de mise à jour : 07/05/2008 08:36:29 Vu : 3 734

Note :
Aucune note

Commentaire sur cette source (60)
Ajouter un commentaire et/ou une note

Description

Ça arrive parfois d'avoir un formulaire avec beaucoup de variables et reprendre chaque variable à travers le $_POST[''] peux devenir fatiguant. Ce script à pour but d'extraire toutes les variables transmises (qui seront transmisent) à la page de traitement.

Le formulaire intégré permet de choisir la façon dont la liste est afficher.

Tout type de document texte est exploitable, y compris les pages PHP directement.
 

Source

  • <?php
  • if(isset($_POST['name_page']))
  • {
  • //extraction du texte à analyser
  • $texte = file_get_contents($_POST['name_page']);
  • //axtraction des varibles contenur entre name=" et "
  • $num = preg_match_all('"`<input .* name="(.*)" .*>`Uis' , $texte, $mots);
  • $j = 0;
  • if($_POST['requete_sql'] == "ok")
  • {
  • echo "CREATE TABLE `MA_TABLE` (<br/>";
  • foreach($mots[1] as $val)
  • {
  • $j++;
  • if($_POST['filtre_radio'] == "ok")
  • {
  • if($val != $vieux)
  • {
  • echo '`'.$val.'` text NOT NULL';
  • if($j != $nb)
  • {
  • echo ',<br/>';
  • }
  • else
  • {
  • echo '<br/>';
  • }
  • }
  • $vieux = $val;
  • }
  • else
  • {
  • echo '`'.$val.'` text NOT NULL'.$j.' '.$nb;
  • if($j != $num)
  • {
  • echo ',<br/>';
  • }
  • else
  • {
  • echo '<br/>';
  • }
  • }
  • }
  • echo ") ENGINE=InnoDB DEFAULT CHARSET=latin1;";
  • }
  • else
  • {
  • foreach($mots[1] as $val)
  • {
  • if($_POST['filtre_radio'] == "ok")
  • {
  • if($val != $vieux)
  • {
  • echo $val.'<br />';
  • }
  • $vieux = $val;
  • }
  • else
  • {
  • echo $val.'<br />';
  • }
  • }
  • }
  • }
  • else
  • {
  • ?>
  • <h2>Extracteur de nom de variables</h2>
  • <p>Cet extracteur a pour but d'extraire les noms des variables de formulaire qui seront transmis.</p>
  • <p>Le mode doublon permet d'éviter que les variables RADIO apparaisse plusieurs fois</p>
  • <p>Le mode Requete génére une requete SQL que vous pourrez copier/coller afin de la modifier et de l'éxcuter. Toutes les variables seront considérées comme des champs texte pour le table sql.</p>
  • <form action="extracteur_de_variables.php" method="POST">
  • <table style="border: 1px black solid;">
  • <tr><td>Donner le nom de la page à analyser:</td><td><input name="name_page"/></td></tr>
  • <tr><td>Filtrage des doublons (recommendé si présence de Radio)</td>
  • <td><input type="radio" name="filtre_radio" value="ok"/>Oui<br/><input type="radio" name="filtre_radio" value="no"/>Non</td></tr>
  • <tr><td>Génération de requete MySQL</td>
  • <td><input type="radio" name="requete_sql" value="ok"/>Oui<br/><input type="radio" name="requete_sql" value="no"/>Non</td></tr>
  • </table>
  • <input type="submit" value="Analyser"/>
  • </form>
  • <?php
  • }
  • ?>
<?php
if(isset($_POST['name_page']))
{
//extraction du texte à analyser
$texte = file_get_contents($_POST['name_page']);
//axtraction des varibles contenur entre name=" et "
$num = preg_match_all('"`<input .* name="(.*)" .*>`Uis' , $texte, $mots);
$j = 0;
if($_POST['requete_sql'] == "ok")
{
	echo "CREATE TABLE `MA_TABLE` (<br/>";
	foreach($mots[1] as $val)   
	{
	$j++;
		if($_POST['filtre_radio'] == "ok")
		{
			if($val != $vieux)
			{
		    echo '`'.$val.'` text NOT NULL';
				if($j != $nb)
				{
				echo ',<br/>';
				}
				else
				{
				echo '<br/>';
				}
			}
			$vieux = $val;
		}
		else
		{
		echo '`'.$val.'` text NOT NULL'.$j.' '.$nb;
			if($j != $num)
			{
			echo ',<br/>';
			}
			else
			{
			echo '<br/>';
			}
		}
	}
	echo ") ENGINE=InnoDB DEFAULT CHARSET=latin1;";
}
else
{
	foreach($mots[1] as $val)   
	{  
		if($_POST['filtre_radio'] == "ok")
		{
			if($val != $vieux)
			{
		    echo $val.'<br />';
			}
			$vieux = $val;
		}
		else
		{
		echo $val.'<br />';
		}
	}
}
}


else
{
?>
<h2>Extracteur de nom de variables</h2>
<p>Cet extracteur a pour but d'extraire les noms des variables de formulaire qui seront transmis.</p>
<p>Le mode doublon permet d'éviter que les variables RADIO apparaisse plusieurs fois</p>
<p>Le mode Requete génére une requete SQL que vous pourrez copier/coller afin de la modifier et de l'éxcuter. Toutes les variables seront considérées comme des champs texte pour le table sql.</p>
<form action="extracteur_de_variables.php" method="POST">
<table style="border: 1px black solid;">
<tr><td>Donner le nom de la page à analyser:</td><td><input name="name_page"/></td></tr>

<tr><td>Filtrage des doublons (recommendé si présence de Radio)</td>
<td><input type="radio" name="filtre_radio" value="ok"/>Oui<br/><input type="radio" name="filtre_radio" value="no"/>Non</td></tr>

<tr><td>Génération de requete MySQL</td>
<td><input type="radio" name="requete_sql" value="ok"/>Oui<br/><input type="radio" name="requete_sql" value="no"/>Non</td></tr>
</table>
<input type="submit" value="Analyser"/>
</form>
<?php
}
?>

Conclusion

Un code assez simple, reprenable facilement pour etre modifier.



 

Historique

23 avril 2008 15:23:39 :
correction de certain bug du au copier/coller et renommage de certaine variable dont le nom n'était pas bien choisi
07 mai 2008 08:36:29 :
suppression des $ma_variable = $_POST['ma_variable'] modification de la Regex pour prendre uniquement les Input.

Commentaires et avis

signaler à un administrateur
Commentaire de neigedhiver le 23/04/2008 15:08:23

Salut,

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...

signaler à un administrateur
Commentaire de azqsazqs le 24/04/2008 10:11:16

En fait, non, preg_match_all() permet non seulement de compter le nombre de résultat, mais aussi de stocké, si parenthèse capturantes, dans un array.


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.

signaler à un administrateur
Commentaire de neigedhiver le 24/04/2008 11:32:23

"En fait, non, preg_match_all() permet non seulement de compter le nombre de résultat, mais aussi de stocké, si parenthèse capturantes, dans un array."

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.

signaler à un administrateur
Commentaire de azqsazqs le 24/04/2008 11:41:50

je reconnais que $nb = count($mots[0]); ne sert à rien.


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 ^^

signaler à un administrateur
Commentaire de coucou747 le 24/04/2008 13:33:28

juste un commentaire au sujet de ton expression reguliere, elle recupere tout les "name", alors que beaucoup de gens mettent des names ailleur. On Trouve aussi des gens qui mettent ca en majuscule, voir moitie majuscule, moitie minuscule, tu devrais donc elargir ta regexp.

signaler à un administrateur
Commentaire de azqsazqs le 24/04/2008 13:45:37

si j'ai bien compris, il faudrait faire un recherche pour prélév le name seulement dans les input.

ca doit pouvoir se faire

signaler à un administrateur
Commentaire de neigedhiver le 24/04/2008 14:07:58

En fait, si je comprends bien, ta source se contente de faire un extract().
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.

signaler à un administrateur
Commentaire de azqsazqs le 24/04/2008 14:11:04

mettez des notes n'hésitez pas.

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.

signaler à un administrateur
Commentaire de coucou747 le 24/04/2008 14:25:23

c'est pas une question de nombres de noms :) perso, j'ai un generateur de formulaires, ca me permet de declarer et utiliser directement un formulaire.

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...

signaler à un administrateur
Commentaire de azqsazqs le 24/04/2008 14:28:27

c'est du PHP objet, et je ne connais pas du tout (pas faute d'avoir essayer).

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.

signaler à un administrateur
Commentaire de neigedhiver le 24/04/2008 14:28:45

Je viens de percuter un truc... (ouais, j'ai mis le temps)
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('"`<input .* name="(.*)" .*>`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...

signaler à un administrateur
Commentaire de azqsazqs le 24/04/2008 14:32:04

je suis d'accord, mais imagine toi en train de faire un formulaire assez gros.

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.

signaler à un administrateur
Commentaire de coucou747 le 24/04/2008 14:51:43

$form=array(
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

signaler à un administrateur
Commentaire de neigedhiver le 24/04/2008 16:15:15

"tu te vois faire un copier collé de tes NAME ? toujours regardé ou tu en es pour voir si tu en a loupé."

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...

signaler à un administrateur
Commentaire de malalam le 24/04/2008 19:08:51 administrateur CS

Hello,

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 ?) ?

signaler à un administrateur
Commentaire de neigedhiver le 24/04/2008 20:59:07

Ben alors patron...

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.

signaler à un administrateur
Commentaire de azqsazqs le 24/04/2008 21:00:28

ben, pour tous vous dire, je travail sur un projet ou un formulaire répercute les données sur des pages à imprimer.

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.

signaler à un administrateur
Commentaire de malalam le 24/04/2008 21:56:46 administrateur CS

Ah en effet suis hors sujet, je n'avais pas relu le code en fait : je pensais l'avoir lu hier ou ce matin, mais ce n'était pas ce code ;-) Je n'avais donc relu que vos commentaires.
Pourquoi pas.

signaler à un administrateur
Commentaire de neigedhiver le 24/04/2008 23:42:16

'soir,

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.

signaler à un administrateur
Commentaire de coucou747 le 25/04/2008 03:24:29

neigedhivert, tu postes a 23h 42 !!! c'est donc une soiree qui se doit d'etre formidable !
(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...

signaler à un administrateur
Commentaire de malalam le 25/04/2008 08:07:52 administrateur CS

Hello,

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é.  

signaler à un administrateur
Commentaire de azqsazqs le 25/04/2008 11:05:14

justement, je fais ce script dans le cadre d'un stage (sinon je fait comme neigedhiver d'habitude) et que je dois réunir des papiers "officiaux" (déclaration, permis de construire...) de façon à ce que en un seul formulaire, je puisse avoir les données nécessaires à une dizaine de circulaires. Donc au niveau temps, ce script est génial, car il est rapide (peut etre pas autant qu'il pourrait l'être avec un codage correct) par rapport à la méthode classic.

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 ^^

signaler à un administrateur
Commentaire de coucou747 le 25/04/2008 13:23:05

Pour le xml, c'est souvent un format d'echange ou de stoquage, mais le faire re-exploiter par du php, c'est faire un truc qui consome des ressources, alors pour un simple formulaire...

signaler à un administrateur
Commentaire de malalam le 25/04/2008 18:35:34 administrateur CS

Non, XML, c'est un "langage" de description de données. Il est certes universel.
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.

signaler à un administrateur
Commentaire de amezghal le 28/04/2008 02:45:27

salut, j'ai pas lu tous les posts
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 .'<br />';
}
?>
et je copie/coller le resultat dans mon script :)

signaler à un administrateur
Commentaire de pokinwilly le 28/04/2008 08:52:23

Hello,

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.

signaler à un administrateur
Commentaire de azqsazqs le 28/04/2008 15:01:58

la solution de amezghal est idéale si on veut retraiter directement les données transmises par le formulaire. toutefois, il faut quand même avoir les noms de variables à la base.

pour la documentation, je pensais que c'était clair, je ferais mieux la prochaine fois.

signaler à un administrateur
Commentaire de coucou747 le 28/04/2008 15:17:50

sa solution ne fonctionne pas avec les <input name="truc[clef]" ...

signaler à un administrateur
Commentaire de amezghal le 28/04/2008 16:12:56

Salut,
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

signaler à un administrateur
Commentaire de azqsazqs le 28/04/2008 16:16:09

pourquoi mettre isset et empty, vue qu'automatiquement ils sont de valeur inverse ?

if(isset($_POST['truc'])) est largement suffisant (ou quelque chose m'échappe)

signaler à un administrateur
Commentaire de amezghal le 28/04/2008 16:43:29

isset => la variable est définie ou pas,
empty => le contenu de la variable est vide ou pas,
mais siu tu dois verifier le contenu apres :p enleve le empty !


signaler à un administrateur
Commentaire de azqsazqs le 28/04/2008 16:52:27

dans certain cas, empty retourne l'inverse de isset (quand la variable n'est pas définie).

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 ?!?)

signaler à un administrateur
Commentaire de azqsazqs le 28/04/2008 16:53:23

ERRATUM: pour le premier exemple, la varible est non définie

signaler à un administrateur
Commentaire de amezghal le 28/04/2008 17:04:16

$a && $b => true SI $a=true et $b=true;

signaler à un administrateur
Commentaire de azqsazqs le 28/04/2008 17:06:17

oui, ca je sais, mais j'essayais de comprende ce qui différencie Isset de empty

signaler à un administrateur
Commentaire de coucou747 le 28/04/2008 17:10:13

$a=NULL; isset et empty retourneront l'inverse, j'ai pourtant dans l'idee que $a est definie...

signaler à un administrateur
Commentaire de amezghal le 28/04/2008 17:11:05

si la variable n'est pas definie:
isset=>false;
empty=>true;

si la variable est define:
isset=>true
empty suivant le contenu de la variable;

signaler à un administrateur
Commentaire de azqsazqs le 28/04/2008 17:13:48

oui, coucou747, mais il a complémenter empty, donc quand $a = null:

isset = true
empty = false
!empty = true

signaler à un administrateur
Commentaire de amezghal le 28/04/2008 17:14:59

donc !empty suffit :p

signaler à un administrateur
Commentaire de azqsazqs le 28/04/2008 17:18:16

dans le cas cas on vérifie le contenu de la variable oui.

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.

signaler à un administrateur
Commentaire de coucou747 le 28/04/2008 17:27:05

Commentaire de azqsazqs le 28/04/2008 17:13:48 .... fake....
<?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...

signaler à un administrateur
Commentaire de azqsazqs le 28/04/2008 19:37:22

effectivement, je suis un peu a l'ouest

signaler à un administrateur
Commentaire de FhX le 03/05/2008 19:14:31

Différence de temps entre $nom et $_POST['nom'] pour l'écriture ?

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

signaler à un administrateur
Commentaire de azqsazqs le 04/05/2008 10:50:59

le but du code n'est pas de gagner du temps sur les $_POST[], mais plutot de retrouver toutes les variables utilisées dans un formulaires.

signaler à un administrateur
Commentaire de FhX le 04/05/2008 20:27:51

"le but du code n'est pas de gagner du temps sur les $_POST[], mais plutot de retrouver toutes les variables utilisées dans un formulaires."

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

signaler à un administrateur
Commentaire de azqsazqs le 05/05/2008 08:57:09

tu post deux fois le même message y a juste la formulation qui change et le fonctionnement du code (le pourquoi de sa création) a été donné dans les post plus haut


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

signaler à un administrateur
Commentaire de FhX le 05/05/2008 20:20:31

Et si tu utilises un formulaire sur ton site, vas tu utiliser ce même type de fonctionnement ??
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.'<br />';
}

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 ? ;)

signaler à un administrateur
Commentaire de azqsazqs le 06/05/2008 21:42:43

a ce que je vois, tu as toujours pas compris.

-------------------------------------------------------
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 ?

signaler à un administrateur
Commentaire de coucou747 le 06/05/2008 21:51:50

"je prefere: echo "salut $nom";"
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...

signaler à un administrateur
Commentaire de azqsazqs le 06/05/2008 21:57:11

ok, pour le coup des variables.


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

signaler à un administrateur
Commentaire de malalam le 06/05/2008 22:25:50 administrateur CS

Hello,

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.

signaler à un administrateur
Commentaire de amezghal le 06/05/2008 22:42:07

Sinon rien d'initié dans ce script(snippet),
et si cet input est dans un commentaire html ?
je crois que DOMDocument est plus approprié...
@+

signaler à un administrateur
Commentaire de malalam le 06/05/2008 23:15:36 administrateur CS

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.

signaler à un administrateur
Commentaire de FhX le 07/05/2008 04:40:33

Je vais rester quand même dans le domaine de la gentillesse :p

"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

signaler à un administrateur
Commentaire de azqsazqs le 07/05/2008 08:30:02

merci pour ta dernière phrase FhX :)

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...