Manipulation d'objets complexes dans un site web - Page 1

Hello,

Cette question ne se limite pas forcément au PHP, mais comme c'est le langage sur lequel je suis parti je crée mon topic ici. Le problème est le suivant : comment faites-vous (ou feriez-vous) pour manipuler (créer ou modifier) des objets "complexes" dans un site ?

Par "objet complexe", je veux dire autre chose qu'un objet qui possède simplement une liste de champs scalaires qui ne dépendent pas les un des autres, et qui peut donc être créé en une seule étape. Par exemple, prenons un objet "Carnet" qui contient une liste d'objets "Contact". Ma classe "Contact" dérive en "Entreprise" et "Particulier" qui ne contiennent pas du tout les mêmes informations. On peut alors imaginer un formulaire qui me propose de créer un "Carnet", avec un bouton pour ajouter un nouveau contact. Il faut ensuite choisir le type de contact ("Entreprise" ou "Particulier"), et en fonction de ce choix les informations qui me seront demandées ne seront pas les mêmes. Mon formulaire ne peut donc pas être constitué d'une seule page, il y en aura au minimum 2, et l'objet "Carnet" en cours de construction doit être persistant entre les deux.

Voici les solutions que je connais, et les inconvénients de chacune :

- On peut enregistrer l'objet "Carnet" en cours de construction avec la même couche de persistance (fichier plat, base SQL...) que celle utilisée pour conserver tous les "Carnet"s créés. Le problème c'est que si l'utilisateur interrompt la création en cours de route, on aura un objet temporaire dans la base qui ne sera pas automatiquement nettoyé. On peut toujours lui mettre un flag "est_temporaire" et purger les objets temporaires à intervalles réguliers, mais il faut ordonnancer une tâche dédiée à ça, et je ne trouve pas cette solution très élégante.

- On peut enregistrer l'objet "Carnet" en cours de construction dans une session. Mais je n'aime pas trop les sessions, principalement parceque c'est incompatible avec la navigation par onglets (tous les onglets partagent la même session, donc si on essaie de créer deux objets simultanément, il y en a un qui écrase l'autre). On peut tricher un peu et créer des "contextes de session" pour gérer plusieurs onglets, mais ça devient compliqué.

- On peut sérialiser l'objet "Carnet" en cours de construction et le passer en POST à travers les différentes pages du formulaire. Ça gère les onglets multiples et ça ne laisse pas de saletés si on interrompt la création en plein milieu. En revanche, il faut être très vigilant niveau sécurité puisque l'utilisateur peut facilement trafiquer l'objet entre deux pages, et ça peut être rapidement très lourd puisqu'il faut répéter un champ POST potentiellement long à chaque <form> contenu dans la page (et quand il y en a une dizaine, ça finit par se sentir).

Quelle est la solution qui vous semblerait la meilleure parmi celles-ci, et si vous en connaissez une (ou plusieurs) autre(s), quelle(s)-est/sont elle(s) ?

Merci

[zeph] je suis un boulet, j'ai cliqué sur le bouton "éditer" au lieu de "citer"... le post ci-dessous est incomplet, j'ai perdu l'original :/

Après, je ne comprends pas trop pourquoi tu ne veux pas créer un vrai objet « Carnet » vide que l'utilisateur modifie (et puis supprime si ça lui plait pas) plutôt qu'un objet virtuel /temporaire contenant d'autres objets virtuels/temporaires. Ça simplifie énormément la tache si c'est possible (=> solution 1 en light)

[ ... ]

Par contre tu as oublié la solution « Je fais tout côté client en DHTML, puis j'envoie un gros paquet au serveur. » (Mais le défaut est que c'est difficile de reprendre une opération interrompue parce que ta connexion sux, ou autre, donc à éviter sur de grosses quantités de données)

La notion de transaction dans les sgbd est-elle utilisable ?
Mettre les données temporaires dans la portée de session, identifiées par un identifiant donné dans la requête (de façon à régler le problème des onglets) c’est pas si mal ? (solution 2 quoi)

[edit] arg j'ai détruit ton post... cf ./2, désolé :/

Après, je ne comprends pas trop pourquoi tu ne veux pas créer un vrai objet « Carnet » vide que l'utilisateur modifie (et puis supprime si ça lui plait pas) plutôt qu'un objet virtuel /temporaire contenant d'autres objets virtuels/temporaires. Ça simplifie énormément la tache si c'est possible (=> solution 1 en light)

Parceque mon exemple est mal choisi

Un carnet vide serait cohérent, mais dans mon cas un objet "incomplet" ne doit pas exister (ou en tout cas ne doit pas être affiché à l'utilisateur tant qu'il n'est pas entièrement renseigné), donc je suis obligé de maintenir une séparation entre les objets "pas finis" et les objets "finis".

Par contre tu as oublié la solution « Je fais tout côté client en DHTML, puis j'envoie un gros paquet au serveur. » (Mais le défaut est que c'est difficile de reprendre une opération interrompue parce que ta connexion sux, ou autre, donc à éviter sur de grosses quantités de données)

Ça n'est pas toujours possible : selon les choix que je fais au début de la construction de mon objet, je peux avoir besoin d'informations spécifiques en provenance de la base de données pour continuer (envoyer l'intégralité de la base à l'utilisateur pour gérer tous les cas possible n'étant bien sûr pas envisageable).

Sasume (./3) :
La notion de transaction dans les sgbd est-elle utilisable ?Mettre les données temporaires dans la portée de session, identifiées par un identifiant donné dans la requête (de façon à régler le problème des onglets) c’est pas si mal ? (solution 2 quoi)

Oui, mais c'est quand même assez lourd comme mécanisme. L'avantage de stocker en base est que ça factorise le code : on peut réutiliser le même pour l'enregistrement temporaire et l'enregistrement définitif. Sinon je n'ai pas compris le rapport avec les transactions ?

./3 > Une transaction va être annulée à chaque fois que tu fermes la connexion SQL, donc à chaque fin d'éxécution du script, non ?
(À moins d'utiliser une connexion persistante, mais ça entre de toutes façons en conflit avec le système des onglets multiples ^^)
./4 > Ah c'est malin !
Bon, sinon http://dev.mysql.com/doc/refman/4.1/en/memory-storage-engine.html ? :]
(Ok, tu n'utilises peut-être pas MySQL, peut-être même pas un vrai sgbd, mais c'est une idée ^^)
Après pour nettoyer la base de données (si c'en est une) y'a quand même un moyen pas trop vilain de faire avec un timestamp sur l'enregistrement principal.
Sinon, la 1 et la 2 sont quasiment équivalentes (à part au niveau du code en lui-même où la 1 a un avantage si tu as déjà du code qui fonctionne sur de vrais objets) donc heu… Voilà quoi…

Zephyr (./4) :
Ça n'est pas toujours possible : selon les choix que je fais au début de la construction de mon objet, je peux avoir besoin d'informations spécifiques en provenance de la base de données pour continuer (envoyer l'intégralité de la base à l'utilisateur pour gérer tous les cas possible n'étant bien sûr pas envisageable).

Tu as un exemple où ça ne passerait pas, même avec plein de petites requêtes XmlHttp bien organisées ?

Non, mais ça nécessite quand même à déporter une grande partie de la logique de manipulation de l'objet côté interface. Le résultat serait très bon, mais je sais pas trop pourquoi, ça me gène toujours d'avoir une interface qui fait plus que recueillir de simples champs et qui contient du vrai code.

Mais ça reste peut-être quand même la meilleure solution ^^

Pourquoi ne pas combiner 2 et 3 ? je m'explique :

Zephyr (./1) :
(tous les onglets partagent la même session, donc si on essaie de créer deux objets simultanément, il y en a un qui écrase l'autre)

Ben pas forcément, tu peux transmettre en POST seulement quelques informations (un identifiant par exemple) et avoir l'essentiel du contenu qui est sauvegardé dans ta session. Quand tu crées un objet ça crée un identifiant qui n'existait pas encore (donc pas d'écrasement possible). Ainsi tu évites les interférences et tu n'as pas à sérialiser un énorme truc à chaque fois, et du point de vue sécurité il suffit de vérifier que l'identifiant appartient bien à la session. Non ?

Sinon à première vue je ne vois pas de solution autre que ces trois-là (ou des variantes)

Personnellement, je passerais par des sessions, quitte à ce que chaque variable soit en fait un tableau avec un identifiant d'onglet.

(pour les transactions je me demandais simplement si elles étaient utilisables, mais d’après ./5 non)

Ok, je suis passé par des sessions sans identifiant pour l'instant, je les ajouterai si vraiment la navigation avec plusieurs onglets est indispensable.

Merci pour vos suggestions

pour ma part, je ferais tout le formulaire sur une seule et unique page html, avec différentes "onglets" qui peuvent être mis à jour via de l'ajax en fonction des choix. à chaque étape, tu va dans l'onglet suivant, l'utilisateur peut faire précédent et revenir à l'onglet précédent. le formulaire englobe TOUS les onglets, et est soumis à la fin. ainsi pas de session, pas d'objets incomplets ou autres. tout n'est enregistré qu'à la fin !

si l'utilisateur peut faire "précédent", ça reload toute la page donc il faut bien avoir stocké l'objet en session ou en base, non ? (ou alors tu parles juste de pouvoir changer d'onglet via un mécanisme ajax)

[edit] ah non tu peux aussi jouer avec les ancres (#blabla), mais c'est vraiment un bricolage immonde cette technique je trouve :/

effectivement c'est la solution la plus agréable, mais pour le coup j'ai sacrément la flemme

vivi, je parlais bien juste de changer d'onglets, pas d'utiliser les ancres. et pas besoin d'ajax, tu affiche juste l'onglet précèdent et tu caches l'actuel, mais pt de vue html, les 2 onglets sont toujours présents dans des divs séparées

j'aime pas non plus les ancres, meme si dans le cas présent, ca pourrait être utile

Ah ok. Alors ça n'est pas possible sans au minimum un peu d'ajax (et donc pas mal de modifications au niveau du code pour pouvoir afficher séparément certains éléments, c'est ce que je n'aime pas avec ajax), cf. réponse au 2eme [cite] du post ./4

(et puis un objet complexe peut contenir d'autres objets complexes, etc... il n'est pas forcément faisable d'avoir un nombre prédéfini de formulaires "à plat")

Pourquoi ce n’est pas possible sans ajax ?
Il faut du JS pour cacher/afficher les différentes étapes, mais le bouton submit peut être un vrai bouton html, non ?
En fait je trouve que c’est la meilleure solution. Sauf pour ceux qui ont désactivé le JS

ceux là, tu mets juste un message avertissant qu'il faut forcement le JS pour aller sur ce site. temps-pi pour eux !

Nan, le JS ne sera pas forcément indispensable, mais ils risqueront de se taper un formulaire à rallonge…

Quoi que, si les objets du formulaires sont reliés les uns avec les autres, il faut peut-être mettre à jour ou faire apparaître certains champs en fonction d’autres, donc du coup le JS sera presque indispensable.

Le top serait donc de faire la version HTML classique, en plusieurs pages, pas forcément agréable à utiliser, utilisant la session pour stocker d’éventuels résultats intérmédiaires, et par-dessus ça, pour ceux qui ont le JS, surcharger le comportement pour faire apparaître le joli formulaire à onglets…

Il y en a beaucoup qui n’activent pas le JS ? (je pense surtout aux blackberries et iphones)

Sasume (./17) :
Quoi que, si les objets du formulaires sont reliés les uns avec les autres, il faut peut-être mettre à jour ou faire apparaître certains champs en fonction d’autres, donc du coup le JS sera presque indispensable.

Même, regarde bêtement l'exemple de Zephyr… Tu peux avoir plusieurs pages « Ajouter un contact », dont le nombre ne peut-être déterminé à l'avance: c'est typiquement un truc qui ne peut être géré que de manière dynamique.

Maintenant, de nos jours il ne doit plus y avoir tant de monde qui désactive le javascript. Désactiver le javascript aujourd'hui c'est un peu comme quitter sa maison pour aller vivre dans une caverne. Si c'est fait sciemment par l'utilisateur (i.e. ce n'est pas une limitation qu'on lui impose) c'est une preuve de grande connerie. Et à mon avis, à moins de cibler précisément ce type de personnes, tu peux sagement les ignorer.
Après, il faut savoir ce que tu cibles (utilisateurs, plateformes), mais dans le cas général, c'est bête de brider tes possibilités (tant que tu fais bien ton boulot hein !) pour 2-3 péons dont tu n'as en fait rien à faire.

C'est comme si fallait faire les sites sans images et sans souris pour ceux qui utilisent lynx ^^

Y en a tout de même qui n'ont pas le choix (aveugles, par exemple).

Bah rien n'interdit de faire un site beau et accessible, par contre ^^
Les technologies existent déjà, sont là pour ça, et certaines depuis très longtemps il me semble.
(Et les aveugles peuvent bien utiliser un navigateur moderne avec javascript activé quand même, non ?)

GoldenCrystal (./21) :
(Et les aveugles peuvent bien utiliser un navigateur moderne avec javascript activé quand même, non ?)

Il me semble qu'il y a des navigateurs spéciaux (en mode texte + lecture du texte ou braille), et ça m'étonnerait qu'ils aient le javascript

Il me semble que certains aveugles utilisent Lynx, justement, soit avec un écran braille, soit avec un logiciel de synthèse vocale. Et Lynx ne gère pas le JavaScript.

Le JavaScript est une fonctionnalité optionnelle selon la spec HTML, un site est censé marcher sans.

c'est ça, et puis on reçoit ses pages web par email aussi pas vrai?

./18 En fait je n’aurais pas dû employer le terme désactiver. Effectivement, ceux qui désactivent le JS, c’est tant pis pour eux. Mais les téléphones qui permettent d’aller sur internet prennent-ils en charge le JS ?

Sasume (./25) :
Mais les téléphones qui permettent d’aller sur internet prennent-ils en charge le JS ?

Ceux avec Opera Mobile / Safari Mobile / IE Mobile / Chrome Mobile, oui

squalyl (./24) :
c'est ça, et puis on reçoit ses pages web par email aussi pas vrai?

Tu crois vraiment que les navigateurs pour aveugles prennent en charge le JS ?

pourquoi pas

Y'a quand même une autre raison valable pour désactiver le JS : la sécurité. Je me demande si certaines entreprises ne l'imposent pas, d'ailleurs.
Et sinon, personne ici n'utilise NoScript ou un truc similaire ?

Ben quelles failles de sécurité entraîne le javascript de nos jours ? Si t'utilises un navigateur moderne je vois pas de souci moi
(Et puis les gens a qui on a imposé une limitation on y peut rien. À toi de voir si c'est ton marché; dans le cas général, non)
Sinon pour l'histoire des aveugles sous OSX on a voice-over et sous windows y'a des outils équivalent donc je vois pas pourquoi ils devraient utiliser un navigateur merdique tel que lynx.
Je veux dire, en dehors de linux, tous les OS modernes (bon ok en fait, juste Windows et OSX) on des fonctionnalisés d'accessibilité (Linux n'est même pas accessible aux utilisateurs voyants )
Alors quoi… L'aveugle utilise Lynx ça veut dire qu'il utilise Linux… Être aveugle implique d'utiliser Linux ? Je crois pas… Ben si ça les limites je les foutrai perso dans le même sac que ceux qui désactivent le JS.

Tu racontes n'importe quoi ^^