bonsoir,

j'aimerais savoir s'il est possible dans une page une php d'afficher des checkbox ou des boutons radio si dans le champ type_champ_reponse d' une base de données il y a des valeurs comme "checkbox, radio, liste".

merci de votre aide

Hum, il faudrait peut-être plus de précisions mais si je comprends bien tu récupères la valeur de ta colonne, et ensuite un simple if/else et tu affiches le code HTML correspondant à la valeur non ?

oui, c'est pas trés clair
dans ma base de données j'ai cette colonne :


j'aimerais savoir si c'est possible d'afficher par exemple des checkbox rien qu'en récupérant la valeur "checkbox" lors de la requête.

ça me parait compliqué car il y a des valeurs differentes (checkbox, boutons radios, select, etc..) qui s'affichent de façon différente en php

j'espere avoir été plus clair :S

salut,

Ta base n'est pas correctement modélisé, il serait mieux d'avoir une table contenant les types de champs.

Ensuite tu as simplement le type de champs dans un select.


les différent type de champs ne s'affichent pas de manière différente en php, c'est du html !

Tu peux te faire une petite fonction qui en fonction du type affiche le bon champs html.


@+

...Ta base n'est pas correctement modélisée, il serait mieux d'avoir une table contenant les types de champs...

Pas d'accord : compte tenu du nombre limité de types de champs de formulaire existant, une colonne de type ENUM m'apparait au contraire tout à fait appropriée. Cependant, compte tenu des valeurs possibles pour ces mêmes champs et de la structure des données à traiter, il est possible que le défaut de modélisation, s'il existe, ne soit pas à ce niveau-là.

À priori, cette colonne n'existe que dans cette table. Si on devait la trouver dans d'autres tables, alors il serait effectivement peut-être pertinent d'en stocker les valeurs dans une table à part pour la remplacer par une clé étrangère dans chacune de ces tables.

Là règle s'établit de la manière suivante : on définit si une donnée est ou non une propriété d'une entité, donc ici si le type de champ est une propriété de la question ou si c'est une entité à part. Ici, je devine une table « questions » pour une application de test ou de sondage par exemple. En fonction de la réponse attendue, on doit définir le type de champ de formulaire approprié. Si c'est le cas, une colonne de type ENUM est assez appropriée. Le problème pourrait se poser si les réponses peuvent ou non être des choix multiples, auquel cas, il faudra pour chaque question, stocker plusieurs réponses, et par forcément le même nombre pour chaque question. Mais même là, le type de champ reste ici une propriété de la question, la réponse étant une entité à part liée à la question dans une relation 1:1/0:n, ce qui signifie qu'à une réponse ne correspond qu'une et une seule question mais qu'une question peut présenter zéro à n réponses.

Pour la question de départ maintenant : la réponse est oui. Ce que je m'explique mal, c'est que tu poses la question. Je m'interroge donc sur le raisonnement utilisé qui soulève ce problème. Si je suis dans le vrai quant au type d'application, lorsque tu effectues la requête pour récupérer la liste des questions, tu récupères du même coup la question et le type de champ approprié pour la réponse : où se situe donc ton problème pour générer ta page ?

Pas d'accord : compte tenu du nombre limité de types de champs de formulaire existant, une colonne de type ENUM m'apparait au contraire tout à fait appropriée. Cependant, compte tenu des valeurs possibles pour ces mêmes champs et de la structure des données à traiter, il est possible que le défaut de modélisation, s'il existe, ne soit pas à ce niveau-là.

À priori, cette colonne n'existe que dans cette table. Si on devait la trouver dans d'autres tables, alors il serait effectivement peut-être pertinent d'en stocker les valeurs dans une table à part pour la remplacer par une clé étrangère dans chacune de ces tables.

ce n'est ni "normalisé" (1ère règle normal, enum c'est mysql, etc) ni évolutif simplement (cf ta signature XD).

Ceci ce n'est que mon avis et l'habitude de prévoir un truc évolutif.

Après je crois qu'effective ceci reste valide ^^
[quote="moogli"
Tu peux te faire une petite fonction qui en fonction du type affiche le bon champs html.
[/quote]

@+

...ce n'est ni "normalisé" (1ère règle normal, enum c'est mysql, etc) ni évolutif simplement (cf ta signature XD).

Pas normalisé, soit, mais c'est toujours utilisable dans la mesure où, quel que soit le SGBD utilisé, il existe une manière de le faire en utilisant un type normalisé et éventuellement un trigger ou une fonction utilisateur, voire pour certains SGBD un type défini par l'utilisateur. J'avais dans cet esprit monté une base sous Oracle avec des clé primaires auto-incrémentées alors que « AUTO_INCREMENT » n'existe pas dans Oracle. Faudrait-il se passer des facilités offertes par certains SGBD au seul prétexte que ce n'est pas dans une norme partagée par tous les SGBD ? Ce serait se limiter et se compliquer pas mal la tâche.

Pas évolutif, c'est à voir : est-ce que ça a vraiment besoin de l'être ? Ici, il s'agit de types de champs de formulaires, c'est donc limité par une norme définie par les DOCTYPE. Au pire, on pourrait prévoir de nouveaux types de champs, ce qui à priori est peu probable, mais rien n'interdit d'utiliser un type SET peut-être plus souple au lieu d'un type ENUM, ce qui permettrait d'ajouter les nouveaux types lorsqu'il en arrivera un nouveau tous les 36 du mois.

Le fait que le type ENUM soit propre à MySQL n'est pas bloquant à mon sens et ce type est approprié dans bien des cas. Suppose par exemple une table stockant des personnes avec nom, prénom et civilité : est-ce que pour stocker la civilité (M., Mme, Melle) tu feras une table à part ? Note que je l'ai déjà vu : sémantiquement, ce n'est certes pas faux, mais en pratique, ça me semble une aberration. Il n'y a qu'un cas où ça pourrait à la rigueur passer, c'est ajoloca qui m'avait suggéré cette option, c'est dans le cas d'une application internationale où dans une table civilité, outre le libellé on aurait une colonne précisant la langue. Mais là, le problème de l'internationalisation ne se pose même pas puisque le même mot désigne une balise de code HTML qui sera toujours la même quelle que soit la langue affichée dans le site.

Je ne crois pas qu'il faille être trop à cheval sur certaines normes, faute de quoi, on passerait pour des intégristes bornés. C'est une question de circonstances, il faut de la logique et de la mesure en tout

my 2¢

merci pour vos réponses,

la base de données est celle d'un site que je dois refaire (je suis en stage de fin de formation infographiste) pour afficher les demandes de devis coté client et récupérer les infos coté admin, mon probléme pour afficher ma page php c'est que je n'ai jamais vu lors de la formation la fonction enum dans une table, j'ai donc recherché comment récupérer et afficher les valeurs et je pense utiliser un switch ensuite pour afficher le type de champ approprié suivant la valeur récupérée.

la personne pour qui je refais ce site veut aussi pouvoir ajouter des questions dans la table à partir d'une page coté admin.

ENUM est simplement un type de données, au même titre que VARCHAR ou INT ou TEXT, etc.. à ce détail près que lors de la définition de la colonne quand on crée la table, on définit plusieurs valeurs possibles et une valeur par défaut.

Donc on le récupère de la même manière que n'importe quel autre champ étant entendu que ce sera une des valeurs possibles. Et lorsque tu dois faire une insertion dans cette colonne, tu ne peux pas utiliser de valeur autre qu'une de celles définies dans la table. Ce qui veut dire que lorsque tu aura dans une requête SELECT la colonne en question, ça te retournera une valeur unique en fonction de la ligne, ce sera donc text ou checkbox ou textarea ou autre chose..

ENUM n'est donc pas une fonction, mais un type de données, voir dans la documentation