Symfony Rouging caractères speciaux

16 févr. 2009, 04:12

Pour une question de lisibilité on m'impose d'écrire des urls comme :
http://www.phpfrance.com/blog/php-pdo

dans le routing.yml si on définit ainsi

Code : Tout sélectionner

maRoute:
  url: /blog/:cat-:tag
  param: { module: blog, action: list }

ça ne fonctionne pas est c'est normal car on peut définir des paramètres avec des caractères spéciaux, donc comment dire à symfony que le nom du paramètre est terminé ?

16 févr. 2009, 12:13

Je fais court mon train arrive : dans le livre, au chapitre sur le routage cherche "separator" dans la page. Ajoute le tiret comme séparateur.

16 févr. 2009, 14:30

Merci naholyr

16 févr. 2009, 16:04

Bon après test j'y arrive pas :'(

Voici mon message d'erreur

Unable to parse "questionsReponses/:cat-:spec/*" route near "-:spec/*".

voici mon routing.yml

Code : Tout sélectionner


qa4:
  url: /questionsReponses/:cat-:spec/*
  param: { module: questionsReponses, action: index }

et mon factories.yml

Code : Tout sélectionner

routing:
  class: sfPatternRouting
  param:
    load_configuration: true
    suffix:             .
    default_module:     default
    default_action:     index
    variable_prefixes:  [':']
    segment_separators: ['/', '.', '-']
    variable_regex:     '[\w\d_]+'
    debug:              %SF_DEBUG%
    logging:            %SF_LOGGING_ENABLED%
    cache:
      class: sfFileCache
      param:
        automatic_cleaning_factor: 0
        cache_dir:                 %SF_CONFIG_CACHE_DIR%/routing
        lifetime:                  31556926
        prefix:                    %SF_APP_DIR%

16 févr. 2009, 17:38

Il manque pas une partie à ta route ?

genre :

Code : Tout sélectionner

qa4: 
  url: /questionsReponses/:cat-:spec/* 
  param: { module: questionsReponses, action: index } 
  requirements: { cat: \w+ , spec: \w+ }

A+

Pascal

16 févr. 2009, 20:04

Et si jamais la solution de pascal ne répond pas au problème, à tout hasard, version de symfony ? ^^

17 févr. 2009, 15:17

La partie requirements n'est pas obligatoire, mais je viens de tester au cas ou et j'ai toujours la même erreur :'(

Je suis en 1.1

17 févr. 2009, 15:47

La partie requirements n'est pas obligatoire, mais je viens de tester au cas ou et j'ai toujours la même erreur :'(

Je suis en 1.1

il est temps d'expérimenter les joies de la migration en 1.2

sinon tu peux tenter de faire des routes de test plus simples, sans le "*" à la fin, mais avec le "-", pour comprendre un peu mieux ce qui se passe.

A+

Pascal

17 févr. 2009, 16:23

Projet de trop grosse taille pour envisager une migration

, d'autant plus que la 1.2 n'est visiblement qu'une version "batarde" en attendant la 1.3... Et puis je trouve que c'est du n'importe quoi aussi de sortir une version 4-5 mois après la release de la précedente, surtout quand il y a eu les vacances entre les deux

17 févr. 2009, 16:25

Si j'enlève le /* il me dit

Unable to parse "questionsReponses/:cat-:spec" route near "-:spec".

17 févr. 2009, 16:29

c'est clair que la V1.1 est une erreur.

Pour la migration vers 1.2, j'ai fait ce qui était dans la doc, mais bon, le mode "je me démerde à la main" a pris le dessus. entre autres bugs apparus :
- un module qui ne marche plus (probablement lié au SQL inside)
- une route qui ne marchait plus
- il fallait être connecté pour s'inscrire au site

pour tes routes, est-ce que d'autres routes ressemblent à celle-ci (genre pattern pouvant être reconnu par plusieurs routes différentes) ?

A+

Pascal

17 févr. 2009, 17:03

Hum non je pense pas

qa1-2:
url: /questions-reponses
param: { module: questionsReponses, action: index }

qa2:
url: /question/:title/:id/*
param: { module: questionsReponses, action: question}

qa4:
url: /questionsReponses/:cat-:spec/*
param: { module: questionsReponses, action: index }

:s

18 févr. 2009, 00:12

Attention au niveau des versions, bon là c'est trop tard puisque le projet est commencé, mais il faut bien lire les différentes déclarations avant de choisir

En l'occurrence la 1.0 est stable, la 1.1 n'était qu'une version de transition entre 1.0 et 1.2 (introduction de sfForm, introduction des classes Configuration, mais perte de l'admin generator, compat 1.0 encore maintenue pour quelques éléments), alors que la 1.2 est une vraie release actuellement dite stable, mais à mon avis il faut toujours attendre une stabilité de plusieurs mois avant d'utiliser un framework pour un projet en production.
La 1.3 est à nouveau une version de transition (a priori entre la 1.2 et la 2.0).

Moralité : c'est la 1.0 que vous auriez du utiliser

Mais bon là n'est pas le sujet. Je vais tester de mon côté mais étant en déplacement je risque de ne pas pouvoir te répondre "pour de vrai" avant ce week-end.

18 févr. 2009, 00:30

Ca se passe comment l'admin générator sous 1.2 & .3 ? Car visiblement c'était un vrai casse tête la transition vers sfForm

Au passage sfForm BEURK

18 févr. 2009, 10:59

je n'ai pas utilisé l'admin generator, par contre sfForm oui.

alors au début, beurk, mais ensuite c'est balèze.

points positifs :
- génération du model et des formulaires, echo $form dans le template : on a un prototype très rapidement
- le model objet permet de modifier un élément via plusieurs formulaires facilement (héritage) par exemple un profil qui hérite du form de base, et plusieurs forms pour modifier la présentation, le mail, l'avatar
- personnalisation assez simple des champs du formulaire
- personnalisation relativement simple des validateurs
- création de validateurs custom facile (cf mon tuto : http://forum.symfony-project.org/index.php/t/16172/ )
- les cas généraux sont documentés

points négatifs :
- la doc est incomplète pour les utilisations poussées
- la doc présente plusieurs points d'entrée : docs officielles, blog, API... il faut savoir où chercher

mon résumé : puissant mais pas assez limpide dans la documentation

A+

Pascal

Symfony Rouging caractères speciaux

Qui est en ligne