Framework: [proposal] Allow passing parameters to controller that are not in request URI.

[RyanThompson]

It would be helpful in tricky situations to allow passing parameters to the controller@method that are NOT included in the request URI. Without closures.

Consider a bit of logic that handles a specific request URI but does not have access to an associated request path for itself.

Being able to tell the route handler (not using closures cause they don't cache) what entity to return by ID for a given route path would be very helpful.

Route::any('my/awesome/page', 'My\Awesome\PageHandler@view')->with(['pageId' => 12]);

I know in may cases you could store the matching path in the database but that's not the cleanest option in my opinion when you could route a parent/child/path to an ID (just one example).

I hope this makes sense - granted this only one example, I've run into it before and have seen discussion online to handle it. My current solution is mapping to mycontroller@view_5 and split on "_" and go from there.. not ideal.

[phanan]

Would love to have this too. :+1:

[lukasgeiter]

In which order would those parameters be passed if route parameters are present? Just afterwards? Then I'd see a problem with optional route parameters...

[juukie]

If you already know what value the parameter will be, why wouldn't you be able to use it in your controller method. It seems useless.

[Sladewill]

I agree with @juukie why have a static value on there, if you already knew you wanted that page id you would store it in the controller method, or pass it through the url.

[selmonal]

I think it is unnecessary.

[Gwill]

-1

[RyanThompson]

@lukasgeiter @juukie both of you guys are approaching if from an optional parameter type perspective (like a typical ID or flat slug) - it's more of telling the controller some data - not asking for it from the URI. If the URI could support the parameter and make sense / give an elegant solution 100% of the time this would not be totally unnecessary. But there are times when you don't want the URI to hold an ID or whatever for SEO reasons / client demands / what have you.

And don't get me wrong, this is perfectly possible using closures, but closure routes can NOT be cached.

This is also not practical for a developer as we can map directly to a method in majority of cases but rather handling DYNAMIC requests. I ran into this issue in our Pages module - a user makes a (possibly nested) page - the module dumps a routes file:

This generates the routes file.
https://github.com/anomalylabs/pages-module/blob/master/resources/assets/routes.stub

This returns the page response with magic method.
https://github.com/anomalylabs/pages-module/blob/master/src/Http/Controller/PagesController.php

It would make more sense to tell the controller what ID to use rather than use trickery to do it.

It seemed odd that I could not TELL the controller certain information without using a closure.. IMO There needs to be an interface to TELL the controller something without relying solely on the URI.

[Sladewill]

I think its more a question why are you doing processing outside of the Controller?

[RyanThompson]

It's just some simple generation (that little loop is the extent of it) - for each page generate it's route definition in a routes.php file which is included later. Everything else is done past the controller (response / etc).

The tricky thing is they're routes I can not define as a dev but are generated based on the end user's decisions - Laravel just needs to handle em.

Admittedly it's not a common thing.. but kinda pointed out the oddity in the interface for me is all.

[Sladewill]

Seems wrong to have a loop to create dynamic routes, theres another way of doing it like:

<?php
Route::get('{slug}', ['as' => 'page.show', 'uses' => 'PageController@getShow'])
    ->where('slug', Closure);
?>

Then just cache the closure results.

[RyanThompson]

That's along the lines of where I was experimenting prior, yes - except pages can be nested in this case so {slug} would be {path} where path is (.*), then look it up by walking up the URI segment by segment. Totally doable and I think there were a couple other ideas I tried too but they added a look up / closure or something that would either not be cached or hijack the other possible public routing or something.. not as nice as:

Route::any('products/laravel/about/origins', 'My\Controller@view')->with(['id' => 32]);

Doesn't that look and read more elegantly?

Perhaps there is indeed a better way but I've been thinking about this one for a bit before posting the issue ^_^

I think this is a small, but fundamental interface issue - not necessarily a this / that use case or approach to a problem type issue when it comes down to it.

[dillinghamio]

Worth mentioning,

// --------------- routes ---------------------

Route::get('page', [
    'uses' => 'App\Http\Controllers\Controller@page',
    'page_id' => 1
]);

// -------------- controller -------------------

public function page(Request $request)
{
    dd($request->route());
}

// ---------------- output ---------------------

array:3 [▼
  0 => true
  1 => array:2 [▼
    "uses" => "App\Http\Controllers\Controller@page"
    "page_id" => 3
  ]
  2 => []
]

[RyanThompson]

That'll do! Wow thanks a ton man - I've searched and searched for this. A little wonky where it's at but 100% perfect.

Thanks again!

For anyone looking for similar behavior - it's in the route's actions: $request->route()->getActions()

[dillinghamio]

@RyanThompson ah I was playing with it in Lumen, which returns an array. no ->getActions()

[ghost]

@RyanThompson . Works perfectly for defined Route actions. Any idea on how to make the same work for Route::resource ? Can't find a way to make it work.