Feature #27116

Routing: Declared variables only available in POST but not in GET regexpr signature

Added by Fernando Arconada about 10 years ago. Updated over 9 years ago.

Status:
Closed
Priority:
Should have
Category:
MVC - Routing
Target version:
-
Start date:
2011-05-29
Due date:
% Done:

0%

Estimated time:
PHP Version:
Has patch:
Complexity:

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 methodsResolvedBastian Waidelich2011-05-292013-04-13

Actions
#1

Updated by Bastian Waidelich about 10 years ago

  • Category changed from Configuration to MVC - Routing
#2

Updated by Bastian Waidelich over 9 years ago

Hi Fernando,

Route defaults merge POST and GET vars.
do you have a concrete example of what you're trying to achieve?

#3

Updated by Fernando Arconada over 9 years 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

#4

Updated by Bastian Waidelich over 9 years 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

#5

Updated by Fernando Arconada over 9 years 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

#6

Updated by Bastian Waidelich over 9 years 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.

Also available in: Atom PDF