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 ?