recuperer données formulaire pour afficher en tableau

Jc · 25-06-2012 01:05:41

Bien que ce formulaire pique un peu les yeux et risque d'être peu lisible pour certains internautes, sache que pour développer un tel formulaire il va vous falloir
- Au moins 5 tables pour respecter une bonne normalisation des données.
- Un dépôt de fichier digne de ce nom car le dépôt de fichier se fait dans un contexte public. (cf un lien du forum sur ce propos).
- d'un contrôle de saisie utilisateur solide et efficace.

Exemple de formulaire HTML5 (non PHP) + JQUERY (posté en ajax) en cliquant ici.

Dernière modification par Jc (25-06-2012 13:13:36)

pimiento · 25-06-2012 14:45:10

Je t'accorde volontiers que ce formulaire pique un peu les yeux, mais c'est bien ce dont je parlais l'autre jour et les soucis d'un webdesigner qui doit rester à l'écoute de la personne pour laquelle il travaille.
Et le fait que ce soit un document jpeg n'arrange rien à sa lisibilité.
En gros je n'ai pas choisi les couleurs, perso j'aurais évité de faire un truc qui fait trop fleuriste ou peintre, mais quelque chose de plus sérieux et plus conventionnel, mais bon...

Sinon, je me tente un truc:
Donc 5 tables, et je pense qu'il faut un index du coup.

Pour l'index j'ai choisi la facilité et donner un N° de dossier a chaque porteur de projet (plus exactement à chaque projet, car un porteur de projet peut éventuellement avoir plusieurs projet).

1° table nommée "DonneesPerso" (je ne sais pas si on peut mettre des majuscule dans cette nomination, sinon donnees_perso est peut être plus approprié)
numero_dossier | nom | prenom | tel_perso | statut

2° table nommée "Categorie" (incluant un index, la categorie dans laquelle le projet se trouvera sur l'annuaire, le domaine d'activité precis par exemple vente de poulets, et le nom de l'entreprise ou association).
numero_dossier | categorie | domaine | intitule |

3° table nommée "Contact" (incluant un index, N° de tel professionnel, adresse, ville et Email).
numero_dossier | tel_pro | adress | ville | email

4° table nommée "Commentaires" (incluant l'index, les champs suivants parcours exécuté pour créer l'entreprise, d'où vient cette envie de créer, quel expérience en tirez vous),
numero_dossier | parcours | envie | exp

5° table nommé "images"

numero_dossier | logo | carte_de_visite | photo

Voilà j'espère que j'ai bon...

Rappel:
Le formulaire devra être vérifié par un membre de l'asso avant d'être affiché dans une page.
Toutes les clés ne seront pas toujours remplies (enfin, je crois que le terme clé est bien le bon...dans mon cas ça correspondrait aux champs???)
La dernier table ne devra par être remplie par le formulaire mais par mes soins après traitement des images

Dernière modification par pimiento (25-06-2012 15:02:24)

Jc · 25-06-2012 16:29:07

Bonjour,

Tu n'y es visiblement pas du tout.
Je t'invite vivement à construire ce que l'on appelle un MCD (Modèle conceptuel de données) pour t'aider dans ta démarche.
Tu as commencé à te poser certaines bonnes questions pour ce faire, comme par exemple "un porteur de projet peut éventuellement avoir plusieurs projets", car ce besoin est déterminant dans les relations entre les différentes entités définissant ton cahier des charges. Tu pourrais continuer en déterminant par exemple si plusieurs contacts peuvent être définis au sein d'un même projet, si le modérateur peut refuser le projet et y apporter une annotation particulière, etc...

Bref, tu commences déjà par te rendre compte que la possibilité qu'un porteur de projet puisse avoir plusieurs projets, implique une révision complète de ton formulaire. Car le niveau 1 d'une normalisation correcte correspond à ce que ton modèle préserve l'unicité des données. Or avec ton formulaire actuel, si le même porteur de projet désire ajouter un nouveau projet, il est obligé de se créer un nouveau compte comme porteur de projet et il sera défini 2 fois comme porteur de projet dans la base de données.

Suite à l'intervention de MK concernant la remarque des tutos du site du zéro, j'y suis allé faire un tour pour la première fois il y a peu de temps, et force est de constater que leur tutos sont assez avancés et bien construits. Je t'invite donc à y aller faire un tour pour la partie MySQL.

Cordialement,

Jc.

pimiento · 26-06-2012 10:04:13

Bonjour,
Effectivement je commence à comprendre certaines choses grâce à vous et je vous en remercie.
Mais bon j'ai aussi l'impression de devoir vous sortir les vers du nez :P

Jc a écrit :

Tu n'y es visiblement pas du tout.

Merci pour tes encouragements :)

Jc a écrit :

Je t'invite vivement à construire ce que l'on appelle un MCD (Modèle conceptuel de données) pour t'aider dans ta démarche.

Je demandais si il existait une méthode voir des outils pour aider a concevoir un jeu de tables dans le post #16, j'en attends encore la réponse.
Et voilà que j'ai aujourd'hui un début de réponse a cette question après avoir fait une recherche sur la signification de MCD sur google image. ici

Jc a écrit :

Tu as commencé à te poser certaines bonnes questions pour ce faire, comme par exemple "un porteur de projet peut éventuellement avoir plusieurs projets", car ce besoin est déterminant dans les relations entre les différentes entités définissant ton cahier des charges. Tu pourrais continuer en déterminant par exemple si plusieurs contacts peuvent être définis au sein d'un même projet, si le modérateur peut refuser le projet et y apporter une annotation particulière, etc...

Oui bien sur, le modérateur peut refuser une inscription à l'annuaire c'est justement son utilité. Il ne pourra qu'accepter l'inscription (et éventuellement modifier certaines informations érronées) ou la refuser.
Je cherche à faire quelque chose le plus simple possible donc il n'y aura qu'un seul contact.

Jc a écrit :

Bref, tu commences déjà par te rendre compte que la possibilité qu'un porteur de projet puisse avoir plusieurs projets, implique une révision complète de ton formulaire. Car le niveau 1 d'une normalisation correcte correspond à ce que ton modèle préserve l'unicité des données. Or avec ton formulaire actuel, si le même porteur de projet désire ajouter un nouveau projet, il est obligé de se créer un nouveau compte comme porteur de projet et il sera défini 2 fois comme porteur de projet dans la base de données.

Même si c'est extrêmement rare (à ce jour ça n'est encore jamais arrivé) il faut effectivement en tenir compte.
Par contre je ne vois pas comment gérer cette contrainte d'unicité pour le moment (si vous avez une piste)
L'annuaire doit faire ressortir les projets et non les porteurs de projet, et on ne souhaite pas que ces porteurs de projet soient obligés de créer un compte pour s'y inscrire donc difficile de leur allouer un Id ou chose de la sorte.
J'ai justement utilisé le système de N° de dossier pour éviter ce genre de soucis bien que ça ne le solutionne pas complètement.
Donc l'annuaire n'affichera pas cette information (N° de Dossier) car peu parlante pour quelqu'un qui souhaite consulter l'annuaire, mais bien utile pour l'indexation.
Je pense déjà que ça risque de créer des problèmes de sécurité et c'est pour cela que j'avais pensé à instaurer ce système avec modérateur, car pour le moment on ne tiens vraiment pas à mettre en place cette option d'inscription et création de comptes.
Toutefois si on doit vraiment le mettre en place, on le fera.

Jc a écrit :

Suite à l'intervention de MK concernant la remarque des tutos du site du zéro, j'y suis allé faire un tour pour la première fois il y a peu de temps, et force est de constater que leur tutos sont assez avancés et bien construits. Je t'invite donc à y aller faire un tour pour la partie MySQL.

J'y avais déjà jetté un oeil, mais vraiment furtif. Je prendrais le temps d'approfondir (quand j'aurrais mieux assimilé les 20 pages de texte données par MK).
Tout comme je jetterais un oeil sur la recherche googlesque concernant les MCD.

Merci.

Maljuna Kris · 26-06-2012 11:40:18

Attention à propos du MCD, il s'agit d'un document d'étape dans la démarche de modélisation MERISE. Souvent des outils affirment être des supports de MCD ( c'est de cas de MySQL WorkBench par exemple) alors qu'ils sont, en fait, des supports de MPD, offrant d'ailleurs souvent la possibilité de rétrogénéré (inverse engineering) ce MPD à partir d'une base de données existante.
A ce stade, cela t'apparaît probablement abscons, mais nous préciserons cela à l'avenir, l'important est que tu sois prévenu.
Essaye déjà de comprendre la démarche MERISE de modélisation des données d'un système d'information, notamment ces étapes qui, d'une certaine façon, auraient du conduire à imaginer le patron de conception (pattern design) MVC. Attache-toi surtout à comprendre l'intérêt "des formes normales", et veille à toujours concevoir des bases de données qui soient au moins en FN3.

Jc · 26-06-2012 12:18:34

Il faut bien comprendre que te ton modèle tu peux en extraire que les informations nécessaires que tu souhaites. Après il faut que ton modèle puisse gérer intégralement tes besoins, sinon tu seras amené tôt ou tard à recommencer peut être de zéro ton application avec une migration de données d'un modèle vers un nouveau modèle.
Si tu gardes ce modèle de formulaire et que la possibilité de créer un projet supplémentaire pour un porteur de projet doive pouvoir s'exercer, alors tu n'as pas le choix: il te faut créer un mode connecté dans lequel chaque porteur de projet va pouvoir rajouter des projets a son projet initial.
Les problèmes de sécurité que tu évoques n'ont pas de raison d'être à partir du moment où les choses sont faites comme elles doivent être faites. Il est même prématuré d'en parler à ce stade de ton projet.

En résumé, tu peux très bien te contenter que ne développper au niveau interface que 10% des possibilités de ton modèle, ce qui compte, c'est de ne pas devoir changer de modèle à chaque changement applicatif : ce n'est pas viable.

++

Dernière modification par Jc (26-06-2012 12:20:31)

pimiento · 26-06-2012 12:53:42

En résumé, tu peux très bien te contenter que ne développper au niveau interface que 10% des possibilités de ton modèle, ce qui compte, c'est de ne pas devoir changer de modèle à chaque changement applicatif : ce n'est pas viable.

Je ne suis pas sur d'avoir bien compris cette phrase.

Tu me conseilles de faire des tables plus évoluées (plus fournies) quitte a ce que le formulaire ne le soit pas plus, juste en prévision ?

J'ai l'impression de me noyer dans un verre d'eau...
Mais il suffirait pas de pouvoir donner plusieurs N° de dossier par porteur dans la table nommée DonneesPerso ?
Bon je suis conscient que ça ne gère pas encore les homonymes mais c'est juste pour la réflexion...

Dernière modification par pimiento (26-06-2012 13:08:23)

Jc · 26-06-2012 15:37:47

Il te faut modéliser le cahier des charges de ton application et de son évolution à moyen terme (+ loin possible idéalement). Ensuite tu développes ton application au fur et à mesure de tes besoins, sur un modèle qui ne change pas. Cela n'a rien à voir avec le fait qu'une table soit plus fournie ou non ce qui n'a pas de sens d'ailleurs.

Jc · 28-06-2012 22:21:28

Si tu n'as toujours pas compris, prenons l'exemple des projets évoqués. Même si dans les 6 prochains mois les porteurs de projets ne pourront pas créer plus d'un projet sur le site, il faut que ton modèle le prévoit dès le départ, de façon à ne pas tout recommencer quand tu vas mettre en place cette fonction.

pimiento · 29-06-2012 18:07:12

Si capiche, j'ai juste eu une petite commande qui m'a pris un peu de temps car urgente.
Donc pour récapituler:

Je dois effectuer une page par rubrique (les rubriques incluent plusieurs activité), incorporant un tableau qui lui même intègrera l'annuaire.
Dans cet annuaire doit apparaître une ligne par projet (dossier),
Dans l'ordre doit apparaitre:
- Le logo, ou carte de visite si le logo n'existe pas/n'est pas fourni, rien si rien n'est fourni, la raison sociale,
- L'activité précise,
- nom, prénom du responsable, tel perso, statut,
- La ville,
- Le telephone pro, l'adresse, le contact sous forme d'un lien qui dirige vers une page formulaire type qui enverra le message directement dans la messagerie concernée (possible avec un faux popup?),
- Une rubrique à propos avec un début de descriptif et a la fin un lien "en savoir plus" ouvrant un panneau (faux popup) incluant des commentaires et une photo si celle ci est fournie (si c'est pas trop compliqué, sinon juste un lien en savoir plus). Ce faux popup aura trois paragraphes maximum de 450 caractères maximum chacun, une ou deux photos si fournies.

Le tout sera du html généré avec du php.
Les données seront récupérées d'une bdd.
Cette bdd sera remplie via un formulaire php qui sera au passage validé par un modérateur.

Il faudra toutefois prévoir:
- Que l'administrateur puisse modifier les infos avant de valider,
- Que les infos incomplètes puissent être stockées et non affichees afin de les sauvegarder pour y rajouter les données manquantes quand elles seront fournies via formulaire (je suis pas sur que la méthode soit vraiment bonne),
- Une mise à jour possible des données (via formulaire?),
- Pouvoir supprimer un dossier obsolète (archiver?),
- Qu'un porteur de projet puisse avoir plusieurs dossiers,
- je pense que ce formulaire ne sera pas vu par plus de dix personne simultanément (du moins pour l'instant, et je pense pas vraiment que cela change),
- d'après ce que je comprend, un n° de dossier ne serait pas le mieux pour l'indexation, un n° d'adhérent serait il plus approprié?
- une sauvegarde de la bdd,
- la plupart des informations ne sont pas obligatoires ( bien que vivement recommandée),
- ne pas imposer un enregistrement de membres serait un plus,
- si un ou plusieurs fichiers image seront fournis par l'intermédiaire du formulaire, ils devront être stockés, non affichés. Puis après vérification et traitement seront inclus en bdd puis affichés.
- De l'aspirine,
- du café,
- une bonne dose de courage.
- et de la patience...

Bon j'espère ne rien avoir oublié ...

Maintenant je me demande si quand Jc parlais de plusieurs table, c'était pas plutôt:
- une table remplie par le formulaire (avant validation)
- une table remplie apres validation d'un modérateur
- une table de sauvegarde,
- etc...

Encore merci de votre aide.

Dernière modification par pimiento (30-06-2012 08:42:56)

pimiento · 01-07-2012 08:06:56

Ha si j'oubliais un truc, il y a pour l'instant à peine un peu plus de 1000 projets menéS à terme et environ 200 projets voient le jour par an.
Comme quoi l'idée que chacun peut créer son emploi à partir du moment ou il est bien accompagné n'est pas si farfelu

Dernière modification par pimiento (01-07-2012 08:07:59)

Jc · 01-07-2012 15:09:52

Bonjour,

Je pense que c'est une bonne base de travail. Par contre ne pas imposer un enregistrement des membres, difficile pour faire un suivi de dossier. Il faut toutefois pouvoir récupérer le nom,prénom, adresse email valide et n°de tel. Si on se limite à cela, aucune confidentialité des données ne pourra être garantie car les données vont transiter par mail (pas de mail sécurisé ici) et donc en clair pour tous ceux que ça interesse.

pimiento · 01-07-2012 16:39:33

Salut,
Je ne vois pas ce que tu entends par "les données vont transiter par mail", si tu parles des données fournies afin de s'inscrire sur l'annuaire, ce ne sera pas le cas car le formulaire sera en ligne et devra être validé par modo.
Si tu parles du fait que mettre son adresse mail directement sur une page est un peu risqué car elle risque d'être récupérée par un bot à des fin de phising ou tout ennui de la sorte, je pensais mettre les adresse dans des faux popups mais je ne suis pas sur que ça garantisse que l'adresse ne soit pas récupérée par des bots.
Mais peut être que tu parles simplement du formulaire d'envoi de message, qui je n'ai pas précisé sera bien sur envoyé après vérification des champs.
Ou peut être tu penses à tout autre chose, dans ce cas je veux bien que tu précises.

Jc · 01-07-2012 17:15:17

Bonjour,

Comme je l'ai dit, je parlais du suivi de dossier. Si le membre n'a pas d'espace connecté sur le site, cela oblige dans ce contexte à ce que tout le suivi du dossier + modération se fasse par mail. Vu qu'un projet doit rester discuté dans un contexte privé, et vu le caractère public non sécurisé des mails (contexte usuel d'utilisation), un espace membre sécurisé en https reste la seule alternative possible vis-à-vis de vos obligations légales sur ce point.

++

Dernière modification par Jc (01-07-2012 17:19:54)

pimiento · 01-07-2012 18:13:46

Je voyais plutôt une gestion du style :
Le porteur remplit le formulaire, les données s'enregistrent dans une table dédiée uniquement accessible à la modérateur (donc privée), une fois les données vérifiées et validées elle s'enregistrent dans une autre table qui serait elle publique.

Mais peut être que c'est le terme projet qui porte à confusion, ce qu'on appelle projet dans ce cas, et en fait un projet déjà abouti et qui n'a plus rien de privé.

Mais comme précisé, plus avant si ce doit être plus simple que les membres inscrits doivent s'enregistrer ça se fera.
Par contre nous tenons vraiment pas a ce que l'annuaire ne soit visible que par les membres car dans ce cas il perdrait grandement de son utilité qui est de faire connaître ces nouvelles entreprises/associations.

Mais tes remarques me font penser que au minimum il faut un espace privé pour les modos, même si les membres ne s'inscrivent pas.

Merci de tes précisions.

Dernière modification par pimiento (01-07-2012 20:41:43)

pimiento · 05-07-2012 10:05:47

Il me semble que cette suite d'opérations soit un peu trop compliquée pour mon niveau (ou plutôt mon absence de niveau) ...
Je me demandais si ce n'est pas plus pertinent de gérer un maximum de chose "à la main", donc je pense que je vais laisser tomber le formulaire en ligne (du moins pour le moment).
Je vais surement informer les porteurs de projet par mail en y incluant le formulaire, en leur demandant de répondre en me remplissant ce formulaire.
De là je vais peut être pouvoir remplir la BDD moi même et l'afficher par php ...

Vous en pensez quoi? Mise à part que ça va me donner pas mal de boulot, est ce une solution viable?
Peut être aussi que ça me fera un premier pas vers le php/MySql sans que ce soit trop compliqué à ce niveau là ?

Dernière modification par pimiento (05-07-2012 10:07:55)

PHP|Débutant :: Forums

Advertisement

#26 25-06-2012 01:05:41

Re : recuperer données formulaire pour afficher en tableau

#27 25-06-2012 14:45:10

Re : recuperer données formulaire pour afficher en tableau

#28 25-06-2012 16:29:07

Re : recuperer données formulaire pour afficher en tableau

#29 26-06-2012 10:04:13

Re : recuperer données formulaire pour afficher en tableau

#30 26-06-2012 11:40:18

Re : recuperer données formulaire pour afficher en tableau

#31 26-06-2012 12:18:34

Re : recuperer données formulaire pour afficher en tableau

#32 26-06-2012 12:53:42

Re : recuperer données formulaire pour afficher en tableau

#33 26-06-2012 15:37:47

Re : recuperer données formulaire pour afficher en tableau

#34 28-06-2012 22:21:28

Re : recuperer données formulaire pour afficher en tableau

#35 29-06-2012 18:07:12

Re : recuperer données formulaire pour afficher en tableau

#36 01-07-2012 08:06:56

Re : recuperer données formulaire pour afficher en tableau

#37 01-07-2012 15:09:52

Re : recuperer données formulaire pour afficher en tableau

#38 01-07-2012 16:39:33

Re : recuperer données formulaire pour afficher en tableau

#39 01-07-2012 17:15:17

Re : recuperer données formulaire pour afficher en tableau

#40 01-07-2012 18:13:46

Re : recuperer données formulaire pour afficher en tableau

#41 05-07-2012 10:05:47

Re : recuperer données formulaire pour afficher en tableau

Pied de page des forums