Définition des routes

Bonjour à tous,

comme beaucoup je débute avec symfony avec le tutoriel Jobeet, et j'ai un problème de compréhension pour définir les routes. Le principe je l'ai compris, et je voudrais savoir si j'ai bien compris le rôle de url_for.

Dans cette partie : http://www.symfony-project.org/jobee...ion_des_routes, il est dit qu'on veut obtenir une URL de ce genre :

Citation:

---

/job/sensio-labs/paris-france/1/web-developer

---

Dans routing.yml on écrit :

Citation:

---

job_show_user:
url: /job/:company/:location/:id/:position
param: { module: job, action: show }

---

Est pour accéder à cette url, le lien est :

Citation:

---

url_for('job/show?id='.$job->getId().'&company='.$job->getCompany().
'&location='.$job->getLocation().'&position='.$job->getPosition())

---

L'id n'est pas au bon endroit, est-ce une erreur?
Le helper url_for, remplace les caractères '&' et '=' par '/', c'est ça son rôle?

Ensuite, dans la partie http://www.symfony-project.org/jobee...se_de_la_route

J'aimerai savoir si j'ai bien compris.
Avec l'entrée "options", on lie une route avec un model, cela est posible que si le model donne accès aux paramètres de la route ici compagny, location...

Est-ce que j'ai bien compris le principe?

Maintenant je comprends pas d'où sort la variable $job, ou est-elle définit...

Voila pour mes questions.

Merci par avance.

L'ordre n'a pas d'importance, vu que tu donnes le nom et que ce nom est le même dans ton url et ta route. Symfony, va, de lui même, mettre en ordre les données.

Tu verras plus loin, qu'il suffit de passer l'objet $job et que la route est capable, seul, d'y récupérer les informations (beaucoup plus simple et plus légé).

Justement, le $job : c'est l'objet doctrine record qui contiens un enregistrement correspondant à un job donc une commande du style $job->getId() va retourner l'id de l'enregistrement contenu dans l'objet $job.

D'accords, enfaite c'est très simple.

Pour l'objet $job, faut-il que ce soit le nom du module ou le nom de la table "JobeetJob" avec le Jobeet en moins, ou alors, je peux mettre n'importe quoi?

D'ailleurs est-ce que les tables on doit obligatoirement les appeler NomProjetNomtable?

Merci.

Citation:

---

Envoyé par ridfa63

Pour l'objet $job, faut-il que ce soit le nom du module ou le nom de la table "JobeetJob" avec le Jobeet en moins, ou alors, je peux mettre n'importe quoi?

---

Dans ton code, plus haut, tu initialises la variable $job avec le résultat d'une requête doctrine qui te retourne un sfDoctrineRecord. Maintenant, le nom que tu donnes à la variable n'a aucune importance, s'il est le même partout.

Citation:

---

Envoyé par ridfa63

D'ailleurs est-ce que les tables on doit obligatoirement les appeler NomProjetNomtable?.

---

Ne pas confondre :

• Nom des tables dans la base de donnée
• Nom des objets du modèle (modèle des données), généré par symfony, pour accéder et gérer les tables
• Nom des objets que tu crées dans ta couche modèle, ou, plus souvent, dans ta couche contrôleur, et qui contiendront les tables (sfDoctrineRecord et les listes d'enregistrement Doctrine_collection) résultat de tes requêtes.

Pour les nom physique des tables, tu peux mettre ce que tu veux, je ne suis pas personnellement partisant de mettre le nom du projet dans le nom de la table, il est rare d'avoir deux projets qui ce partagent la même base de données. Par contre, y mettre un surfixe fonctionnel, oui, cela peut aider à la lisibilité du modèle quant on n'a que les nom de tables (ex, la tables des adresses d'un client deviendrait alors client_adresses). Cela va dépendre d' l'importance du projet et du niveau de modularité souhaité, à terme).

Pour les nom des objets, ils sont définis dans le config/doctrine/schema.yml il est souhaitable qu'ils soit en regard du contenu de la table. Il est souhaitable qu'ils soient au singulier. C'est à partir d'eux que sera généré le modèle objet des données que l'on retrouve dans lib/model/doctrine

Quant au nom des objets résultant des requêtes, il y a deux politiques. Une qui consiste à donner toujours le même nom, quelque soit les données ($data pour les données, $q pour le query par exemple). L'autre qui consiste à donner un nom en rapport au contexte ($job pour un job, $jobs pour une collection de job, $jobQuerry pour la requête,...).

C'est très claire merci.

Bon ben j'ai encore une question, que signifie le point dans l'url qu'on peut voir ici (ce sont les routes générées automatiquement quand on utilise la classe : sfDoctrineRouteCollection):

Citation:

---

job:
url: /job.:sf_format
class: sfDoctrineRoute
options: { model: JobeetJob, type: list }
param: { module: job, action: index, sf_format: html }
requirements: { sf_method: get }

job_new:
url: /job/new.:sf_format
class: sfDoctrineRoute
options: { model: JobeetJob, type: object }
param: { module: job, action: new, sf_format: html }
requirements: { sf_method: get }

job_create:
url: /job.:sf_format
class: sfDoctrineRoute
options: { model: JobeetJob, type: object }
param: { module: job, action: create, sf_format: html }
requirements: { sf_method: post }

job_edit:
url: /job/:id/edit.:sf_format
class: sfDoctrineRoute
options: { model: JobeetJob, type: object }
param: { module: job, action: edit, sf_format: html }
requirements: { sf_method: get }

job_update:
url: /job/:id.:sf_format
class: sfDoctrineRoute
options: { model: JobeetJob, type: object }
param: { module: job, action: update, sf_format: html }
requirements: { sf_method: put }

job_delete:
url: /job/:id.:sf_format
class: sfDoctrineRoute
options: { model: JobeetJob, type: object }
param: { module: job, action: delete, sf_format: html }
requirements: { sf_method: delete }

job_show:
url: /job/:id.:sf_format
class: sfDoctrineRoute
options: { model: JobeetJob, type: object }
param: { module: job, action: show, sf_format: html }
requirements: { sf_method: get }

---

le paramètre url est la définition de l'url qui sera utilisé par la route.

url: /job.:sf_format
donnera : /job.html

url: /job/:id/edit.:sf_format
donnera : /job/34/edit.html si le job a édité est le 34.