Pour l'objet MyUser
Il est l'enfant de sfGuardSecurityUser qui est, de loin, l'enfant de sfUser...
Si tu veux travailler aves symfony, il est indispensable de bien comprendre les implications de la POO. Et donc tous ce qui est objets, propriétés, méthodes et héritage de classes. Comprendre cela, c'est comprendre l'architecture du framework, ou du moins comment en lire la carte, ce qui n'est déjà pas mal.
L'objet user (myUser, le dernier maillon des héritages) a une particularité, une partie de ces données sont sauvegardées entre deux exécutions de ton applications dans une zone qu'on va appelée la session utilisateur. Dans l'objet user de base est définit un sfParameterHolder qui est une sorte de container qui permet de stocker des données sous forme de "nom" associé à une "valeur". Toutes les données contenues dans le sfParameterHolder sont préservées entre deux exécutions dans la session.
Lors de l’authentification d'un user, l'objet sfGuardSecurityUser (qui hérite du sfUser) y stocke l'id de l'utilisateur courant. Il peut être facilement récupéré par la méthode suivante, rajoutée à l'objet myUser, lui même enfant de sfGuardSecurityUser
La méthode getParameter() permet ici de récupérer un paramètre nommé du sfParameterHolder.
Code : Sélectionner tout - Visualiser dans une fenêtre à part
1
2
3
4
5 public function getUserId() { return $this->getParameter('user_id'); }
De la même manière et avec la méthode setParameter(), il est possible d'y stockée une information (l'Id du personnage), de la préserver entre deux exécution dans la session et de la récupérer aussi souvent que nécessaire.
Pour ce qui est des méthodes liste et data.
Désolé, il semblerait qu'un message ai disparu de la base, ce qui peur rendre ce qui suit un peu incompréhensible.
Tu peux accéder aux contrôleurs par des routes. Un des systèmes de route est le DoctrineRoute. L'avantage est qu'en plus de simplement router vers le contrôleur idoine (executeQuelqueChose) il va vérifier qu'il y a des données a affichée et le retourner au contrôleur... Et, si pour un enregistrement seul, il n'y a rien à afficher, il va renvoyer une erreur 404 sans avoir besoins d'écrire la moindre requête et test dans le contrôleur.
On peut regrouper tous les sfDoctrineRoute nécessaire à un CRUD dans une seule collection de routes basée sur un sfDoctrineRouteCollection. Simple et élégant. Par contre, il arrive que, pour une liste, il ne s'agisse pas simplement d'afficher une liste de tous les enregistrements, mais une liste partiel. Par exemple dans ton application, si on veut afficher la liste des personnages, il ne faut afficher que la liste des personnages du joueur actif. Il est donc possible, dans les paramètres de l'objet sfDoctrineRouteCollection de lui préciser la méthode a utiliser sur le modèle pour récupérer la liste, cette méthode retournera donc uniquement les personnage de l'utilisateur courant. De la même manière, si on utilise, pour le personnage, l'id du personnage d'un autre joueur en modifiant l'url il ne doit pas être possible de le modifier, voir même de l'afficher. Donc on va préciser à notre sfDoctrineRouteCollection une méthode pour les données unitaires (un enregistrement) qui ne retourne un sfDoctrineRecord que si l'Id du personnage envoyé correspond à un des personnages de notre utilisateur, null si non, ce qui va généré une erreur 404 si un quidam tente de modifier un perso qui ne lui appartient pas.
Suis-je plus clair ? As-tu eu le message qui me semble manquer ou ne l'ais-je pas validé ?
Partager