Support the ongoing development of Laravel.io →
Requests Input
Last updated 2 years ago.
0

post or get data you'd get through

Input::get('param')

routing shouldn't be one of their job

Last updated 2 years ago.
0

But say for argument sake, I have a controller with a method foo($id). In one part of the application, id comes off the URI (standard). In another part of the application, id is a parameter in an ajax request. How would you call that controller method passing in id from the ajax request.

Last updated 2 years ago.
0
Input::json('id');
Last updated 2 years ago.
0

Controller

class FooController extends BaseController{
  public function bar($id){
    $bar = Bar($id);
    return $bar.somethingImportant();
  }
}

Route #1

Route::get('bar/{id}', 'FooController@bar');

Is it possible in Laravel to add a second route where id is received as post data (Input::get('id)) without modifying the existing route or controller?

Last updated 2 years ago.
0

I have this working, but it's really ugly and I feel like there's got to be a better way to do this.

function postRouter($route, $controller, $method, $postArgs){
  Route::post($route, function() use ($route, $controller, $method, $postArgs){
    $args = array_map('Input::get', $postArgs);
    return call_user_func_array([App::make("TestController"), $method], $args);
  });
}
Last updated 2 years ago.
0

Let's start over: A general principle is that if something is ugly and difficult, it's probable that you're approaching it from the wrong angle. Why are you trying to do it this way? Why can't you POST to bar/123?

Last updated 2 years ago.
0

I'm learning Laravel and I may be bringing in concepts from other MVCs. I prefer to have loose coupling between http requests and controller methods. So I would rather not have a hardwired dependency in the controller that a certain piece of information should be in post, get or the uri. My preference is that all the information that controller needs come in as an argument. I prefer that http dependencies are isolated to the routing level.

One of the other reasons that I'm pursuing this is that I'm learning the framework. I can see the way that it's supposed to be done, but I also wanted to see how flexibly the framework adapts.

Last updated 2 years ago.
0

I think you could use the Request object to get access to the POST params as follow:

public class YourController extends BaseController{
    public $requestparamId;

    public function getYourAction(){
        $this->requestparamId = Request::get('id');
        
    }

    public function getnewAction(){
            
        return View::make('new.action')->with('id', $this->requestparamId);
    }
}

Later in routes.php you can use it:

Route::get('/newaction', 'YourController@newAction');

I think that it is that you need. In the example you can access to the id param and pass to another route, view, and so much.

Otherwise, if you want to access POST params from a form or another POST request param you could use as follow:

public class YourController extends BaseController{
    public $requestparamId;

    public function postYourAction(){
        $this->requestparamId = Input::get('id'); //remember that the action is a POST function/method
        
    }

    public function getnewAction(){
            
        return View::make('new.action')->with('id', $this->requestparamId);
    }
}

Hope it helps you.

Last updated 2 years ago.
0

The role of a controller is to control what the application does when a request is given to it, I don't think it's possible for a controller to effectively function if it has no knowledge of the environment, if you're trying to use one controller for 2 types of request the requests should use a common API, trying to shoe-horn 2 different APIs into one controller seems like a recipe for spaghetti code.

Laravel is exceptionally flexible, you can extend anything, if you did want to do this I imagine the most sensible strategy would be to extend the Laravel request class to mash all request information (get, post, uri) into one data type and then instead of specifying the HTTP verb when defining routes use Route::any, or use a filter to do it if you want to do it per route... that said I disagree with the approach and would not recommend it.

Last updated 2 years ago.
0

Remember that you need to link the request using any flash option because the parameters could be lost between requests.

Last updated 2 years ago.
0

AdamColton said:

I'm learning Laravel and I may be bringing in concepts from other MVCs. I prefer to have loose coupling between http requests and controller methods. So I would rather not have a hardwired dependency in the controller that a certain piece of information should be in post, get or the uri. My preference is that all the information that controller needs come in as an argument. I prefer that http dependencies are isolated to the routing level.

One of the other reasons that I'm pursuing this is that I'm learning the framework. I can see the way that it's supposed to be done, but I also wanted to see how flexibly the framework adapts.

I mean...it's kind of your controller's job to be tightly coupled to the HTTP request, isn't it?

Last updated 2 years ago.
0

I'm not sure. I've been thinking about this. I kind of feel like it's the routers job to be tightly coupled to the http request and the controller and it's the controllers job to be tightly coupled to the models and views.

Last updated 2 years ago.
0

Hi Adam! I understand completely what you were looking for. I feel like it is ugly to do this all the time


public function someAction(Request $request){
           $id = $request->id;
           $name = $request->name;
}

It would be best to have these parameters as the functions params, this way the controller doesn't deppend on how the request params are named.

Have you find any solution to this?

0

Sign in to participate in this thread!

Eventy

Your banner here too?

AdamColton adamcolton Joined 12 May 2014

Moderators

We'd like to thank these amazing companies for supporting us

Your logo here?

Laravel.io

The Laravel portal for problem solving, knowledge sharing and community building.

© 2024 Laravel.io - All rights reserved.