IdentifiantMot de passe
Loading...
Mot de passe oublié ?Je m'inscris ! (gratuit)
Navigation

Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter

Symfony PHP Discussion :

$object->save() : changement de comportement add/update


Sujet :

Symfony PHP

Vue hybride

Message précédent Message précédent   Message suivant Message suivant
  1. #1
    Membre averti
    Homme Profil pro
    Webmaster
    Inscrit en
    Août 2006
    Messages
    55
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France

    Informations professionnelles :
    Activité : Webmaster
    Secteur : Santé

    Informations forums :
    Inscription : Août 2006
    Messages : 55
    Par défaut $object->save() : changement de comportement add/update
    Bonjour,

    J'ai un formulaire dont je surcharge la méthode save() pour effectuer un traitement des données : ou bien un objet similaire existe déjà dans la table (comparaison sur quelques champs) et alors on met à jour l'entrée existante, ou bien cette recherche ne retourne aucun objet similaire et on l'ajoute à la base.

    Je pourrais donc me contenter d'un (en pseudo-code) :
    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
    if($exist = $this->searchObject($object))
      return $this->updateExistingObject($exist); // renvoie sur un Doctrine_Query
    else
      return parent::save($conn);
    Mais je n'aime pas cette étape qui zappe parent::save()... Du coup, je me demandais si en éditant les propriétés de l'objet lui même, on pouvait changer la requète d'ajout en requête d'update. J'ai essayé de simplement faire correspondre l'id de l'objet à celui en base, bien heureusement Symfony me signale un doublon. J'ai aussi naïvement essayé de réassigner l'objet de la base à $this... vous vous doutez du résultat.

    Bref je voulais savoir si vous connaissiez une manière propre de le faire (peut-être en dehors de save() du coup) ou si mon update séparé du départ reste la meilleure solution même si elle ne passe plus par parent::save().

  2. #2
    Expert confirmé
    Avatar de Michel Rotta
    Homme Profil pro
    DPO
    Inscrit en
    Septembre 2005
    Messages
    4 954
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 62
    Localisation : France, Bouches du Rhône (Provence Alpes Côte d'Azur)

    Informations professionnelles :
    Activité : DPO
    Secteur : Distribution

    Informations forums :
    Inscription : Septembre 2005
    Messages : 4 954
    Par défaut
    A vue de nez, et sans avoir creuser la solution.

    Ta proposition me semble raisonnable et très dans le style de framework. Par contre, elle ne me semble pas du tout coller avec le modèle objet de Doctrine et donc me semble irréalisable.

    En effet, dans l'idée de Doctrine, tu prends un objet dans la base (ou tu en crée un nouveau), tu y apportes les modifications nécessaires et tu sauvegardes (que se soit un nouveau ou un ancien).

    Hors toi tu voudrais partir d'un objet "indéfini" qui devra choisir sa manière d'exister, soit je suis nouveau, soit je me sauvegarde, tu vas donc largement à l'encontre du fonctionnement intrinsèque de Doctrine.

    Je pense que le plus simple sera, dans ton contrôleur, de vérifier avant de charger l'objet doctrine. En pseudo code, dans le contrôleur, cela va donner :
    Code Pseudocode : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
     
    Si ObjetExist
         enregistrement = ChargeObjetDoctrine NuméroObjet
    Sinon
         enregistrement = CréeObjetDoctrine 
    FinSi
     
    enregistrement->setDonnee1($Donnee1)
    ....
    enregistrement->save()
    A noter que le si du départ peut se faire simultanément à la récupération de l'enregistrement, si la requête ne retourne rien, l'objet sera null qu'il restera à tester. Avantage, un seul accès à la BDD.

  3. #3
    Membre averti
    Homme Profil pro
    Webmaster
    Inscrit en
    Août 2006
    Messages
    55
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France

    Informations professionnelles :
    Activité : Webmaster
    Secteur : Santé

    Informations forums :
    Inscription : Août 2006
    Messages : 55
    Par défaut
    De ce que tu me dis, je comprends que si on crée un objet (par défaut dans mon cas), Doctrine n'utilise pas la même classe d'objet que si on le modifie, c'est bien ça ? Du coup pas de méthode/valeur possiblement modifiable pour passer de l'un à l'autre et nécessité de déclarer ce que l'on veut faire à l'instanciation. J'ai bon ?

    Le hic, c'est que je ne peux pas le définir à la création du formulaire : des objets existent, l'utilisateur donne des informations valides pour créer un objet, cet objet peut faire partie des objets existants, ou pas. Du coup, peut-être effectivement un test lors de l'action Create correspondante et définir $this->form en fonction (à la manière du $this->forward404Unless() que l'on retrouve classiquement dans les éditions d'objet).

  4. #4
    Expert confirmé
    Avatar de Michel Rotta
    Homme Profil pro
    DPO
    Inscrit en
    Septembre 2005
    Messages
    4 954
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 62
    Localisation : France, Bouches du Rhône (Provence Alpes Côte d'Azur)

    Informations professionnelles :
    Activité : DPO
    Secteur : Distribution

    Informations forums :
    Inscription : Septembre 2005
    Messages : 4 954
    Par défaut
    Non, ce que je dis c'est qu'un objet Doctrine correspond à un enregistrement précis. Pas soit l'un soit l'autre. Du moins pas facilement et ce n'est pas le comportement prévu.

    Mais tu peux parfaitement faire, avec un peu de travail en plus, un form non lié à doctrine, l’alimenter, le récupérer, vérifier les saisie, décider ce que tu fais des données, soit récupérer soit nouveau, mettre les données et enregistrer.

    Tu pourrais probablement créer une classe dans le genre de la sfFormDoctrine qui va gérer cela directement, mais si tu n'as qu'un form à gérer je pense que c'est une perte de temps. Plus propre (quoique) mais beaucoup plus long, sauf si tu connais parfaitement la structure des objets form.

Discussions similaires

  1. Réponses: 3
    Dernier message: 12/04/2010, 15h55
  2. Réponses: 2
    Dernier message: 09/02/2010, 16h43
  3. Réponses: 4
    Dernier message: 09/10/2009, 16h54
  4. Réponses: 8
    Dernier message: 10/11/2008, 08h35
  5. Changement de comportement SAMBA après MAJ
    Par Guig74 dans le forum Réseau
    Réponses: 1
    Dernier message: 07/07/2008, 11h50

Partager

Partager
  • Envoyer la discussion sur Viadeo
  • Envoyer la discussion sur Twitter
  • Envoyer la discussion sur Google
  • Envoyer la discussion sur Facebook
  • Envoyer la discussion sur Digg
  • Envoyer la discussion sur Delicious
  • Envoyer la discussion sur MySpace
  • Envoyer la discussion sur Yahoo