Parameterizable model-binding

[teatreeoilchocolate]

Premise:

Bindings are global cannot be spaced to distinguish between e.g. web and api-routes.
Identifiers for bindings are strings and strings can have collisions.
e.g. (A very contrived example)
User(for the user of the application) and CommentingUser (which has additional conditions(e.g. permissionflag to comment set).

Both are users. Within the request handler it should not matter what condition the user was loaded with.
We would have to maintain dedicated bindings though(at least for CommentingUser).

(And, no, this particular example cannot be solved by gates as the User is object and not subject of the operation.)

Proposition:

Aside from namespacing bindings(which may be a bigger undertaking , discounting that consistency that {user} binds User anywhere in routes(implicit or explicit) or subclassing where CommentingUser extends User- with additional global scopes causing artificial distinctions making the overall handling of this brittle -, configurability comes to mind.

We already have this mechanism in the middleware where we can give parameters to the middleware (e.g. can:......).
Yes, : etc. are special chars in routing. However, we have two sides to this:

• The routing side
• The side that is concerned with replacing and binding.

We already consider EVERYTHING between { and } to be part of the binding. By that token there shouldn't be any difference between {foo} and {foo:bar,barfoo} .
While handling this with a dedicated or even implicit binding may be a bit more work, changing https://github.com/laravel/framework/blob/11.x/src/Illuminate/Routing/Route.php#L1308 the matching for the routes there (didn't look too closely at SymfonyRoute but matching at that point boils down to matching one string against another) to consider not just \{\w\} but also more chars(:,.,etc) would allow us to write a middleware that describes a more generic binding for our domain logic if we need to.
e.g. (very contrived and verbose) {user:key-for-search:randomNonEnumerableIdField#condition[canWriteComments]=true}

and the middleware would look for that model via
User::query()->where('randomNonEnumerableIdField', $valueToUseForModelBinding)->where('canWriteComments', true)

The benefit for this would be a coherent generalization and it would keep the logic binding models of particular types in one place.

[willrowe]

I've had this same issues and have been trying to come up with a simple and maintainable solution for it. I am actually working an a possible PR to add an attribute that can be used in controllers to mark a method as the query resolver for a specific binding that corresponds to a specific model class. The resolver would either build on the default query or return an entirely new query if needed. It would look something like the code below. I'm curious if this would be helpful for your situation as well?

class UserController extends Controller
{
    #[ImplicitBindingQueryResolver('user', UserModel::class)]
    public static function resolveUserQuery(Builder $defaultQuery): Builder
    {
        return $defaultQuery->where('canWriteComments', true);
    }

    public function show(UserModel $user)
    {
        return $user->getKey();
    }
}

[teatreeoilchocolate]

I don't know.
While I am very fond of meta-programming for various reasons this solution strikes me as problematic.

A controller should handle a request, not augment it.
However, a request is something of a hybrid in this instance to my mind.
It describes data a request (pun intended) for processing said data.

If we were to say every controller can overrides/overrides that loading, we would gain nothing from having the request-handler load it upon request-processing. IMHO we would make it worse since it is now ore convoluted. Not unlike hotplugging a middleware into the request-controller to load/alter data in the request.
In such an instance we would get better mileage leaving it up to the handler to load the model thereby abolishing the routing-layer with its injection-capability since it is more direct.

Routes as a whole have a distinct property. They can be grouped web <-> api , user-processing vs. comment-processing or order-processing etc. each and every one with their own identifiers. It ensures that it is a more coherent to handling the data coming in.(which, I think, is also the reason why the idea of a configurable model binding never surfaced before)

If we were to preserve that, either by making model-binding in routes not global or by making it more configurable, I think we get better mileage since we keep current abstractions.

---

edit:
Another thing I would like to add:
Saying that it either adds conditions OR redoes the db-query is interesting.
I imagine having problems with either scalability(I hit the db twice in the worst case for the same thing, with a lot of data and requests that may not be such a good idea) or maintainability(I have varying conditions spread out over multiple constructs interfacing with one another in a potentially complex scenarious 'just' to bind a model as a parameter to a route).
What if my controller handles multiple different models, what if it is only meant for a specific route, etc.
I understand that complexity needs to live somewhere but it does raise the question of necessity.
So, while I do have a usecase and use for such a configurability I would rather keep it simple if possible or at least cut from the same piece of cloth.
It also raises the question of when the builder's query is supposed to be executed to get the actual object. Depending on how it would be wired up it may be deferred compared to what it is now.

[macropay-solutions]

Hi. Maybe our parallel approach to route model bindings can help you.
https://github.com/macropay-solutions/laravel-crud-wizard-free/tree/3.4.14?tab=readme-ov-file#iii2-get-resource

For example you can overwrite the controller getRelated function and introduce additional conditions for both relation or resource on a route that looks like

GET/users/1/comments/5

Another thing is that when you call GET /users/1 vs GET /commenting-users/2 you will not have the problem from laravel built-in mechanism while using a global scope on the commentingUser if it shares the same table with user.