I like this, but I'd actually like to solve it in an easier way: add a commented-out example in the previous section:

contact_process:path:/contactdefaults:{ _controller: AppBundle:Main:processContact }methods:[POST]# or to match GET *or* POST methods# methods: [GET, POST]

What do you think@xelaris?

I usually prefer concise explanations, as proposed by@weaverryan. But in this case, I think it could be better to show a verbose explanation as proposed by@xelaris. Adding a comment is not clear enough for me. Let's ask@xabbuh and@wouterj for their opinion about this. Thanks.

I would have said that the example proposed by@weaverryan would be clear enough.

@javiereguiluz Do you think from your experience about talking with beginners that this is something not so obvious (even with commented out example)?

@xabbuh I don't know which would be the opinion of newcomers. It was just a personal comment. Let me show you a pair of screenshots explainig why I said that.

We have this:

And Ryan proposes to add a comment:

It's not a bad idea at all. But my concern is ... what would happen with the other 3 config formats? For example, consider the case of "annotations":

Before:

After:

But I think we could find a solution: what if we useGET forcontactAction () andGET +POST forprocessContactAction()?

I hadn't thought about the annotations format, so I agree with Javier. But making the process handle get or post might be confusing since it has the same URL as the above, and so will never match in GET. I'm in favor of actually merging as is, after making all this fuss (the additions actually small - mostly code block).

What about using[POST, PUT] (for instance) for processContactForm?

Oh, that's a cool idea - I can't believe I didn't think of that! +1 for making the previous example use Post and Put instead of this new section.@xelaris can you make that change?

Thanks!

Oh yeah, that's indeed a great idea@wouterj.

I like the idea of changing the existing example to demonstrate how to match multiple methods and I changed the PR as suggested by@wouterj. But I have two points about the current state of this PR:

• I noticed that the example doesn't work well with the best practices, as it uses two actions to display and process the form. This was actually a reason for the first version of this PR.
• I'm in doubt ifPUT is a suitable method to send a contact form.

I'm +1 with@javiereguiluz suggestion to change theprocessContactAction() method to matchGET andPOST. This would kill two birds with one stone: Demonstrate how to match multiple routes and fulfill the best practise.
To make the example more consistent then, I suggest to renameprocessContactAction tocontactFormAction and use a comment like// ... display and process a contact form and to changecontactAction tonewsAction with route/news or something and use a comment like// ... display your news.

What are your opinion about this?

@xelaris Good point with the best practices. But wouldn't we then don't have an example with only one allowed method when choosing your solution?

@xabbuh ThenewsAction with route/newswould match onlyGET.

Good point, looks like a good idea then.

I have changed the PR to apply the latest proposal. What do you think about it?

👍 from me

LOVE it. Thanks@xelaris - you rock for your patience and ideas!