Conception d'une application

[-ZN-]

Hello,

je suis en train de concevoir/coder une application php/mysql et j'ai besoin d'une fonction un peu particuliere, j'aimerai avoir des avis sur sa conception...

J'ai 10 pages de saisie de donnees, chaque page genere 1 a n enregistrements sur 10 tables .... le truc c'est qu'il faut que je gere le retour a la page precedente, et donc les updates de mes tables....

est-il mieux d'utiliser des formulaires? je precise:

au bas de mes pages j'ai deux fleches, une "suivante" et une "precedente" ... je peux modifier l'attribut "action" de mon form en fonction de la fleche sur laquelle on clique, + une variable de type hidden qui peut indiquer si on appelle la page pour un update ou la suite

est-il mieux d'utiliser une variable locale (non-globale) de session php (a la place de ma variable hidden)?

A la place de modifier l'attribut "action" de mon form, peut- il etre interressant d'utiliser l'objet javascript history?

Pour effectuer les mises a jour dans ma BDD, (l'utilisateur clique sur la fleche precendent) n'est-il pas plus simple de recuperer l'enregistrement(s), de l'afficher a l'ecran, d'effacer l'enregistrement(s), puis lorsque l'utilisateur clique sur suivant de recreer un nouvel enregistrement? Quel est interet de "update" en mysql?

Beaucoup de questions .... Meme si j'ai une opinion sur la plupart d'etre elles j'aimerai d'autres avis, afin de continuer a apprendre!

Merci d'avance pour vos suggestions, avis et idees,

ZN

[Anonymus]

Pour avoir essayé des choses similaire, je peux te dire que le probleme que tu poses risque de bloquer à cet endroit :

Lorsque l'on envoie une donnée à travers le réseau, elle passe. Si on en envoie beaucoup, elles arrivent aussi à passer. Mais lorsque l'on en envoie trop, elles arrivent déformées, voire même n'arrivent pas du tout.

Au dela de 3 pages de formulaire, tu n'as aucune chance de faire passer tes variables. Il y aura le poids de la page plus le poids des données, ca ne passera pas, tout simplement.

Ce n'est pas possible de faire passer autant d'informations d'une page à une autre. Il faut donc se tourner vers une autre solution.

Bon. Il y a plusieurs facons de faire :

- Tu stocke dans une base de données toutes les informations, jusqu'à la dernière page, et tu traites les informations à la fin, comme s'il s'agissait d'un seul formulaire. Mais il y a le risque que les personnes arretent en cours de chemin, et donc tu te retrouves avec une base à vider de temps en temps, etc. Il y a le risque que, à force de faire des 'aller et retour' entre les pages, tes données finissent par devenir 'n'importe quoi' dans la base, et ce n'est pas la bonne solution non plus.

- Tu sépares ton formulaire en groupes de données logiques, et tu fais remplir ces groupes de données, les uns à la suite des autres. Un formulaire, une fois rempli, est 'inséré' dans la base, et c'est tout. Meme si la personne retourne dessus.

La seconde solution est la plus préférable. Pour ce qui est de l'insertion dans la base de données, et du bouton 'précédent', il faut se rappeler ceci : Lorsque tu envoies un message dans le forum du Hub, par exemple. Si tu fais 'retour', le message est envoyé, tout simplement. Tu reviens bien dans la page 'répondre', mais il est trop tard, la page est déjà envoyée. Limites donc l'utilisation du bouton 'retour', et javascript 'history'.

La facon de faire est donc simplifiée. Tu sépares les données à remplir via ton formulaire, par exemple, comme ceci :

Plan des tables :

VILLE

id_ville

HOTEL

id_hotel

id_ville

CHAMBRE

id_chambre

id_hotel

SERVICES OFFERTS

id_services

HOTEL_SERVICES

id_hotel

id_services

Commences par la table ville. Tu récupères l'id_ville, qui te permettra de remplir 'hotel'. Ensuite, tu remplis 'hotel'. Tu récupères l'id de hotel. Tu as tous les éléments pour faire 'chambres', donc tu fais 'chambres'.

Pour ce qui est des tables jointures, tu t'en occupes lorsque tu as tous les éléments pour le faire, à savoir : id_hotel, id_services, que tu auras gardé jusqu'à la fin.

A la fin du formulaire, tu peux lancer une vérification des tables, pour voir si les tables sont bien 'jointes' les unes aux autres.

Mais, d'une manière générale, avec ce système, tu ne peux pas avoir d'erreurs. Au pire, tu auras une ville sans hotel ? Un hotel sans chambres ? Lors de la vérif, ce ne sera pas difficile à controler.

Bon.. Cet exemple est trivial, c'est pour te montrer ce que c a peut donner, il est vrai que ce n'est jamais pareil, et que ca dépend aussi si l'on s'adresse, via cette interface, au public ou à la partie 'admin'.

Juste une petite chose :

Pour effectuer les mises a jour dans ma BDD, (l'utilisateur clique sur la fleche precendent) n'est-il pas plus simple de recuperer l'enregistrement(s), de l'afficher a l'ecran, d'effacer l'enregistrement(s), puis lorsque l'utilisateur clique sur suivant de recreer un nouvel enregistrement? Quel est interet de "update" en mysql?

N'effaces pas ! Imagines qu'un autre enregistrement ait besoin de cet enregistrement !

Imagines que le client fait tout le formulaire, et cliques une dizaine de fois sur le bouton 'précédent'. Il devrait se retrouver sur la page d'accueil, sans n'avoir demandé d'effacer ses enregistrement, or ils ne seront plus là

Voilà, en espérant t'avoir aidé

Anonymus.

[-ZN-]

Hello,

merci pour ton aide, je vous envoie un peu plus d'infos sur mon programme decidemment tres specifique...

Je bosse pour une boite d'assurance, et mon programme est fait (enfin doit etre fait) pour que les utilisateurs puissent remplir leur declaration d'assurance en ligne ... c'est pourquoi j'ai autant de champs; a peu pres 200 repartis sur 10 pages (on va dire 20 champs par page)

en gros :a chaque page correspond une table .... a chaque page correspond 1 enregistrement sur la table, sauf qq exceptions, ou 1 page genere N enregistrements sur 1 table (on peut avoir plusieur enfants par exemple)

Au debut je me demandais si ca valait la peine d'avoir 10 tables, et apres reflexion j'ai pense que oui ...

sinon le serveur qui m'heberge est mutualise, donc je me mefie des grosses sessions...

j'ai donc code mon appli pour la saisie, rien de trop complexe, mais maintenant je passe a la "gestion des erreurs", si l'utilisateur se trompe il doit pouvoir revenir en arriere ....

Je crois que j'ai trouve un debut de solution que j'ai commene a coder cet aprem mais cela me semble bien complexe ...

comme j'explique dans mon premier post, j'ai deux fleches en bas de ma page, next et back

tu cliques sur next, je positione form.action sur la page suivante, et je transmet une variable pour dire s'il s'agit d'un update ou d'un nouvel enregistrement

tu cliques sur back, form.action pointe sur la page precendente, je transmet une variable pour dire qu'il s'agit d'un retour en arriere, je lis les enregistrements dans ma table et remplis ma page ....

Je sais pas si je suis tres clair c'est assez complique, ca semble marcher, mais n'y aurait-il pas plus simple?

[Anonymus]

Fais une base temporaire, au nombre de tables de ton formulaire, et avec pour nom les numeros de pages. Tu auras ainsi :

Si l'user est sur page 2, alors : vérifier si page 2 existe dans la base.

Si existe, alors $statut='update', et dépiler la table. Sinon, $statut=insert et champs vides.

Voilà.

[-ZN-]

Merci pour tes conseils, je pense avoir trouve une bonne methode, je ne vois pas pour l'instant l'interet d'une base temporaire ... je vais y reflechir pendant le dejeuner

a peluche,

ZN

[Anonymus]

Par contre, je ne comprends pas que tu ai besoin d'autant de champs, et de si peu de tables :/

Bon appétit

Anonymus

[-ZN-]

merci je viens de finir mon dejeuner a 14h58 belle performance

mon appli est particulierement specifique ....

j'mettrai p'tet un p'tit bout de code en ligne ce soir ou demain pour que tu me donnes eventuellement ton avis, la seule facon de progresser c'est en ecoutant les autres n'est ce pas?

bon passons au cafe