Configuration d'un itinéraire dans Symfony avec le même URL, mais différentes méthodes HTTP et les actions du contrôleur

Question

J'ai la configuration des routes suivantes dans une application Symfony:

label: 
    url:   /label 
    param:  { module: label, action: configure } 
    requirements: { sf_method: get } 

label_create: 
    url:   /label 
    param:  { module: label, action: create } 
    requirements: { sf_method: post } 

liés à executeConfigure et executeCreate actions. Ensuite, j'ai une forme configuré de cette façon:

<form action="<?php echo url_for('@label_create') ?>" method="POST"> 
    <?php echo $form->renderHiddenFields() ?> 
    <input type="hidden" name="sf_method" value="post" /> 
    <!-- more stuff here --> 
</form> 

Chaque fois que le formulaire est soumis executeConfigure est exécuté, bien que autant que je sache la route configurée avec POST méthode doit éviter que et exécute executeCreate.

Comment différencier ces deux actions en conservant la même URL?

Merci!

Answer 1

J'ai également eu ce problème et trouvé la réponse dans un ancien message de forum (http://oldforum.symfony-project.org/index.php/t/25750/).

S'il ignore complètement la méthode de demande, il utilise très probablement le sfRoute normal. Vous devez utiliser sfRequestRoute pour rendre le routage "sensible à la méthode". Donc, dans votre exemple, vous allez faire:

label: 
    url:   /label 
    class:  sfRequestRoute 
    param:  { module: label, action: configure } 
    requirements: { sf_method: get } 

label_create: 
    url:   /label 
    class:  sfRequestRoute 
    param:  { module: label, action: create } 
    requirements: { sf_method: post } 

Answer 2

Je l'ai résolu en utilisant ce routage sheme:

users_create: 
    pattern: /
    defaults: { _controller: "RentalAPIBundle:User:create" } 
    requirements: { _method: post } 

users:  
    pattern: / 
    defaults: { _controller: "RentalAPIBundle:User:index" }  
    requirements: { _method: get } 

puis lorsque vous appelez l'URL que vous pouvez soit l'utilisateur d'appel ou de l'utilisateur/GET mais seuls les utilisateurs/pour le POST. Je ne peux pas dire pourquoi mais cela fonctionne