Feature #27116
Routing: Declared variables only available in POST but not in GET regexpr signature
| Status: | Closed | Start date: | 2011-05-29 | |
|---|---|---|---|---|
| Priority: | Should have | Due date: | ||
| Assignee: | Bastian Waidelich | % Done: | 0% |
|
| Category: | MVC - Routing | |||
| Target version: | - | |||
| PHP Version: | Complexity: | |||
| Has patch: | ||||
| Votes: | 0 |
Description
Variables are declared only in the GET signature but you could have something like
-
name: 'algo actions'
uriPattern: 'algo/{@action}(/{myvar})'
defaults:
'@package': Sifpe
'@controller': Empresa
'@action': list
'@format': json
POST:
vars: [myvar2,myvar3]
defaults:
'myvar1': 'somevalue'
'myvar2': 'somevalue'
Related issues
| related to TYPO3.Flow - Feature #27117: Bind routes to HTTP request methods | Under Review | 2011-05-29 | 2013-04-13 |
History
Updated by Bastian Waidelich almost 2 years ago
- Category changed from Configuration to MVC - Routing
Updated by Bastian Waidelich over 1 year ago
Hi Fernando,
Route defaults merge POST and GET vars.
do you have a concrete example of what you're trying to achieve?
Updated by Fernando Arconada over 1 year ago
Yes I did it in the issue text.
But for example I want to declare a variable only available via POST but not GET
Updated by Bastian Waidelich over 1 year ago
Fernando Arconada wrote:
Hi,
But for example I want to declare a variable only available via POST but not GET
Sorry for insisting, but I still don't get the use case.
In the controller there is currently no difference between GET and POST, so what would be the concrete use case?
Is the aim to have a route that only matches, if a certain HTTP method is used? Because that would be fixed with #27117
Updated by Fernando Arconada over 1 year ago
I dont remenber the use case that i had when i filled the issue. May be the problem could be fixed with #27117 at this moment not i'm not sure
Updated by Bastian Waidelich over 1 year ago
- Status changed from New to Closed
- Assignee set to Bastian Waidelich
Fernando Arconada wrote:
May be the problem could be fixed with #27117 at this moment not i'm not sure
I guess so to.
I'm closing the issue for now. If you (or anyone) comes accross the issue again, feel free to re-open.