Discussion :

[Fused]

Voilà un cas intéressant qui n'est pas (ou peu mentionné) sur la toile.

Un objet "document"
Un administrateur se connecte, le modifie.

On veut avoir le suivit des modification et quel administrateur a modifié l'objet document.

Un schéma simplifié qui me parait correct :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
Document:
  actAs:
    Timestampable: ~
    Sluggable: { fields: [name] }
  columns:
    id:             { type: integer, notnull: true, primary: true, autoincrement:true }
    ref:            { type: string(40) }
    name:         { type: string(140) }
    article:        { type: clob }
 
Modification:
  actAs:
    Timestampable: ~
  columns:
    id:             { type: integer, notnull: true, primary: true, autoincrement:true }
    description:    { type: string(140) }
    document_id:    { type: integer }
    user_id:        { type: integer }
  relations:
    Document: { onDelete: CASCADE, local: document_id, foreign: id, foreignAlias: Modifications }
    User:
      class: sfGuardUser
      foreign: id
      local: user_id
      type: one
      onDelete: cascade
      foreignType: one
      foreignAlias: Profile

Quelle est la bonne stratégie pour ceci ? Y a-t-il quelque chose de prévu à la base ?

Ma première idée est d'utiliser un embed form pour les modifications et de réécrire l'executeCreate autogénéré de l'administration pour voir qui a modifié le document.

Mais cela me parait un peu bordélique.

[Michel Rotta]

Je ne pense pas que ce type d'action soit a traiter dans un form.

Par contre, dans l'objet du modèle, avec une réécriture de l'action save() cela me semble une meilleur idée.

Je me méfierais, malgré tout dans ton schéma de la notion de cascade pour l'effacement. Si on supprime un enregistrement, on perd la trace des modifications, y compris la suppression. Est-ce une bonne idée ?

[dourouc05]

Il y a aussi le behaviour de Doctrine Versionable : http://www.doctrine-project.org/proj...rs:versionable

Maintenant, ça doit encore être un peu à tweaker sur les bords, ça ne fait que sauvegarder des copies des enregistrements à chaque modification.

Maintenant, utiliser des forms pour cela... Et si tu devais faire une modification automatique (comme les bots de Wikipedia) depuis ton application ? Tu fais remplir les forms par symfony pour se les renvoyer ?

[Fused]

Bonne remarques en effet, ce n'est pas intéressant de passer par les formulaire.

Je vais passer par la fonction "versionable" doctrine et traquer qui a modifié le document dans la fonction save.

Il n'y a que les administrateurs qui peuvent réaliser des changement donc je pense que cela ne posera pas de problème.

Pour effacer en cascade un enregistrement cela me parait correct... C'est sur que pas moyen de restaurer ou de voir les anciennes version après. A voir de plus près.

Question bête mais c'est bien de la façon suivante ?

Dans Document.class.php :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
  public function save(Doctrine_Connection $conn = null)
  {
    // mes actions pour récupérer l'id de l'utilisateur connecté
   // $id = truc;
    $this->setUserId($id);
    parent::save($conn);    
  }

Comment récupérer le user id ?
Je ne comprends pas j'ai essayé $this->getUser()->getId() et plein de trucs mais j'ai toujours "Doctrine_Null Object()" comme valeur de Id...

J'ai pourtant bien :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

class myUser extends sfGuardSecurityUser

[spikie]

Alors tu peux soit overloader la methode save comme tu le fais.

Sinon il y a la methode preSave si tu ne veux pas toucher a la methode save.

pour récupérer l'utilisateur quand tu n'est pas dans ton controlleur, il te faudra passer par le sfContext.

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
 
$user = sfContext::getInstance()->getUser();

Parcontre veille bien que ton utilisateur soit authentifié! sinon pas d'id

[Fused]

Ah oui en effet, je n'ai pas réalisé que je ne pouvais pas récupérer l'utilisateur dans la couche model de cette façon.

Merci, et super pour les méthodes preSave() et postSave(), c'est quand même bien pensé doctrine !