Discussion :

[Cethywolf]

Bonsoir,
J'ai un système "classique" d'éléments rangés dans des catégories :
shema.yml

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
PageTCategory:
  columns:
    name: { type: string(255), notnull: true, unique: true }
    description: { type: string(255) }
  actAs:
    Sluggable:
      unique: true
      fields: [name]
      canUpdate: true
 
PageT:
  inheritance:
    type:          concrete
    extends:       Page
  columns:
    category_id:  { type: integer, notnull: true }
  relations:
    PageTCategory: 
      onDelete: CASCADE
      local: category_id
      foreign: id
      foreignAlias: PageTx

Et dans mon système de routing, j'utilise le name de la catégorie (": PageTCategory") pour afficher un élément :
routing.yml

Code :

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

1
2
3
4
5
6
7
8
9
t_show:
  url:   /tut/:PageTCategory/:slug
  class: sfDoctrineRoute
  options: { model: PageT, type: object }
  param: { module: tut, action: show }
 
tuto_index:
  url:   /tut
  param: { module: tut, action: index }

Mon problème vient du fait que je peux avoir n'importe quoi dans mon url dans ": PageTCategory", tant que le :slug est correcte, ca passe.

Code :

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

1
2
3
4
/tut/bonneCategorie/bonSlug :        OK
/tut/mauvaiseCategorie/bonSlug :     OK (mauvais fonctionnement !)
/tut/bonneCategorie/mauvaisSlug :    erreur404
/tut/mauvaiseCategorie/mauvaisSlug : erreur404

Quelqu'un saurait comment je pourrais contourner le problème sans avoir à vérifier l'url moi-même dans mon action ?


PS: Si cela est utile, voici le code pour l'action show :

Code :

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

1
2
3
4
public function executeShow(sfWebRequest $request)
  {
    $this->page_t = $this->getRoute()->getObject();
  }

[Michel Rotta]

Si je comprend a peut près le code, j'ai du mal sur les erreurs que tu rencontre.

Les questions :

Dans ta route, tu utilises "/tut/ageTCategory/:slug" hors slug est bien défini dans le modèle, mais PageTCategory semble être le nom du modèle, je n'ai jamais testé ce type de route, dans ce cas, tu récupère le __toString() de l'objet ? Et vu l'objet, que diable peut-il donner de plus que le nom qui est déjà dans le slug ?

PageT qui semble être l'objet que tu cherches à afficher ne possède pas de slug, sauf s'il est défini dans page dont il hérite.

As-tu envisagés de créé dans PageT un slug avec une fonction perso pour le mettre a jour qui inclurait les deux éléments (page et catégorie) ?

Enfin, je ne comprends pas ce qui ne marche pas avec ton tableau des cas d'erreur. Qu'est-ce que mauvaisCatégorie peut être ? Qu'est-ce donc qu'un mauvais slug ? Si les mauvais sont des inventions des utilisateurs, où est le problème de l'erreur 404 ? Et enfin, qu'est-ce donc qu'un résultat OK mais qui ne marche pas correctement ?

[Cethywolf]

Pour l'histoire des slugs, j'ai vu et corrigé le problème après avoir posté.
Et pour répondre à ton interrogation, la classe PageT a effectivement un slug qu'elle étend de la classe Page.

nouveau routing.yml

Code :

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

1
2
3
4
5
t_show:
  url:   /tut/:categorySlug/:slug
  class: sfDoctrineRoute
  options: { model: PageT, type: object }
  param: { module: tut, action: show }

pour obtenir :categorySlug, code de model/doctrine/PageT.class.php :

Code :

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

1
2
3
4
5
6
class PageT extends BasePageT
{
	public function getCategorySlug()
	{
		return $this->PageTCategory->slug;
	}

Je vais essayer d'être plus clair sur mon tableau de fonctionnement :

Code :

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

1
2
3
4
1. /tut/bonCategorySlug/bonSlug :        OK
2. /tut/mauvaisCategorySlug/bonSlug :     OK (mauvais fonctionnement !)
3. /tut/bonCategorySlug/mauvaisSlug :    erreur404
4. /tut/mauvaisCategorySlug/mauvaisSlug : erreur404

bonCategorySlug est un slug existant dans la table PageTCategory
bonSlug est un slug existant dans la table PageT.
mauvaisCategorySlug est un slug NON-existant dans la table PageTCategory
mauvaisSlug est un slug NON-existant dans la table PageT.

OK est la réponse du serveur, c'est à dire qu'il renvoie l'objet PageT demandé.
Or, dans le fonctionnement 2, le serveur devrait renvoyer une erreur404 car le categorySlug n'est pas bon.

As-tu envisagés de créé dans PageT un slug avec une fonction perso pour le mettre a jour qui inclurait les deux éléments (page et catégorie) ?

Ton idée serait peut-être la réponse à mon problème mais je ne vois pas trop comment faire, sachant qu'il faudrait mettre un "/" dans le slug et symfony ne va pas aimer.

[Michel Rotta]

Tu as la possibilité de préciser la méthode a utiliser si tu ne veux pas passer par les fonctionnalités de base de doctrine pour créer le slug (voir la doc de doctrine). j'ai vu passer un truc dans la même veine sur le site de symfony, mais impossible de remettre la main dessus.

Il est normal que ton cas 2 retourne la bonne page sans créer de message d'erreur. En fait, seul ton champ slug est utilisé par le moteur de route pour gérer la liaison avec ta table PageT, un peu comme si tu utilisais un champ Id. Symfony se contente lors du retour d'une url de vérifier ce champ, et pas l'existence de catégorieSlug. De toutes les manières, vu que le slug de la page est unique, vu que ce qui intéresse l'utilisateur est la page, vu qu'il n'y a qu'une catégorie par pages, où est le problème si la catégorie n'est pas correcte dans le liens ? Pas de danger de sécurité, moins présentable, peut-être, pour l'utilisateur. Le seul intérêt du categorySlug dans l'URL est, à mon avis, de favoriser le référencement des articles.

Si tu crées le slug toi même, tu peux utiliser un - en lieu et place du \.

[Cethywolf]

Plus j'y réfléchi, plus je trouve des problèmes de conception dans mon code
Je vais enlever le unique sur le slug du PageT (et le déplacer sur le couple slug/category_id), créer ma propre fonction pour récupérer l'objet (utilisant le categorySlug et le Slug). Ca devrait régler tous mes problèmes de cette façon

Si tu crées le slug toi même, tu peux utiliser un - en lieu et place du \.

Je ne veux justement pas utiliser le - plutôt que le /, l'application garde une certaine logique avec le / :
/tut/ affiche toutes les catégories
/tut/uneCat affiche les PageT de la catégorie uneCat
/tut/uneCat/unPageT affiche le PageT de la catégorie uneCat
C'est un fonctionnement "naturel" (peut-être seulement pour moi ^^) que j'utilise partout dans mes applis/sites web.

Par contre, j'ai une dernière question (en fait 2) :
- Peux-tu me confirmer que quand on étend un model (dans mon cas, Page) on étend aussi les forms, filters, etc liés ?
- Est-ce possible de créer un model abstrait ? Pour qu'aucun module ne puisse l'utiliser directement ?

[Michel Rotta]

J'ai aussi réfléchi, en fait ce qu'il faudrait c'est pouvoir gérer deux slug dans l'URL. Le slug de la catégorie et le slug de la page. Il est possible de spécifier dans la route les champs à utiliser pour récupérer l'enregistrement et ceux uniquement là pour faire jolis. Faudrait que je recherche, j'ai lu cela il y a quelques mois, mais où ???

Je pense que c'est une mauvaise idée de supprimer l'unicité du slug de la page, imagine que tu te retrouve avec deux slug identiques pour une même catégorie, tu la retrouve comment ta page ?

Tu as plusieurs méthodes pour l'héritage dans la structure d'une table, je n'ai pas trop travaillé la dessus, tu as des informations sur le site de doctrine.

Quant tu régénères ton modèle, tu recrées ce qui se trouve dans /lib/<model|form|filter>/doctrine/base, le tous avec un "doctrine:build --all". Par contre, les fichiers que tu modifies qui ne comportent pas le mot base ne sont pas touché (sauf pour les formes avec BaseForm.class.php).

De ce que j'ai expérimenté, si tu modifies ton modèle, tu modifies les fichiers généré, même si c'est le modèle de la table).

Je ne suis pas sur de bien comprendre ta deuxième question. J'espère ne pas répondre à côté de la plaque. Le problème de doctrine c'est que les "tables de base" dont tu te sers sont générées par doctrine et donc entrainent la génération de tous les objets qui vont autour. Il y a bien des possibilités de demander à symfony de ne pas générer form et filtre mais je n'ai aucune idée de ce que cela donne si on le fait sur une table de base par rapport aux tables étendues à partir de celle-ci. A tester.

Code :

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

1
2
3
4
5
6
 
Page:
  options:
    symfony:
      form: false
      filter: false

[Cethywolf]

Je pense que c'est une mauvaise idée de supprimer l'unicité du slug de la page, imagine que tu te retrouve avec deux slug identiques pour une même catégorie, tu la retrouve comment ta page ?

En mettant le couple slug/category_id en unique, je ne pourrais pas avoir 2 pages avec le même slug pour une même catégorie.

En ce qui concerne ma seconde question :
J'ai mon modèle Page de base, qui contient un model, un form et un filtre personnalisés. Mais je veux pouvoir n'utiliser que les "modèles fils" de Page ; que si le modèle Page est utilisé directement dans un module, cela génère une erreur.

[Michel Rotta]

Pour le couple slug, je comprends ta position, même si je la trouve difficile à gérer et que, sans doutes par paresse, je ne appliquée.

Pour la deuxième question, heu

Tu as des objets page et des objets pageT généré, y compris une table page et tous ce qui est page ne te sers à rien... Mais je n'ai pas de solution pour toi

[Cethywolf]

Pour le couple slug, je comprends ta position, même si je la trouve difficile à gérer et que, sans doutes par paresse, je ne appliquée.

C'est une solution qui demande un peu plus de code, mais c'est tout ^^
Je pense que mon "interprétation" est pas très propre au final, mais je reste un débutant en symfony.
Le principal, c'est que ca fonctionne

Pour la deuxième question, heu

Tu as des objets page et des objets pageT généré, y compris une table page et tous ce qui est page ne te sers à rien... Mais je n'ai pas de solution pour toi

Le framework n'est pas fait pour après tout, donc je vais compter sur la rigueur de programmation ^^

Merci en tout cas.
On se revoit au prochain problème