[Request] Object routing

[franzliedke]

It would be awesome if you were able to just pass model objects instead of arrays when generating routes. That would allow for complete flexibility when generating routes, without having to worry about changing the parameter array that is passed everywhere where URLs are generated.

In relation to these issues:
symfony/symfony#5999
illuminate/database#38

(Meaning I've raised this at the Symfony routing level and tried to implement ArrayAccess for models, which should simplify this).

[taylorotwell]

This sounds cool but I don't totally follow. Maybe post some code examples of what this could look like in Laravel?

On Jan 11, 2013, at 5:17 PM, Franz Liedke notifications@github.com wrote:

It would be awesome if you were able to just pass model objects instead of arrays when generating routes. That would allow for complete flexibility when generating routes, without having to worry about changing the parameter array that is passed everywhere where URLs are generated.

In relation to these issues:
symfony/symfony#5999
illuminate/database#38

(Meaning I've raised this at the Symfony routing level and tried to implement ArrayAccess for models, which should simplify this).

—
Reply to this email directly or view it on GitHub.

[franzliedke]

Imagine you generate profile URLs like this all over the place:

URL::route('profile', array('id' => $user->id));

Now you want to change the URLs to include the username. You change the route, now you have to change all the places where you generate the URL.

URL::route('profile', array('id' => $user->id, 'username' => $user->username));

And all that just for a few cosmetic changes (the username isn't needed to identify the user) - changes that should only belong to the routes.
Just imagine if you could do this instead:

URL::route('profile', $user);

Happiness ensues.

[JoostK]

I've thought about this before as well. I think in your Eloquent you have to specify the parts that make up for the secondary key (the id being the primary) and that the values of those fields will be put into segments. Then in the router matching maybe also some magic to convert from these segments to the eloquent model, something along the following line:

Route::get('user/{@User}', function(User $user)
{
    // $user is now an instance of the User class. Here I'm using a type hint which would
    // prevent null values from being put in, but the router can inspect this and just throw
    // an HttpNotFoundException when the selected object is null. When a null value is
    // wanted the route closure must be defined as `User $user = null`, to allow for the
    // null, I think it is possible to read out default parameter values using Reflection.
});

A different syntax for the actual segment(s) can be used, because the Class information is also available in the type hint. Note that {@User} can actually be multiple segments, if e.g. your Eloquent model is defined as the following:

class User extends Eloquent
{
    protected $segments = ['firstname', 'lastname'];
}

This would be VERY cool as you don't even have to handle finding the object and bombing out when the record doesn't exist. There is one problem with it in that it doesn't allow you to set additional where conditions, possibly to do authorization etc.

Also, if no type hint is given you just get an array of all the segments instead of an actual model instance:

Route::get('user/{@User}', function($user)
{
    // $user = ['firstname' => 'Joost', 'lastname' => 'Koehoorn'];
});

You can do very nifty things with this kind of routing 😃

EDIT Additional where clauses can probably be set if you specify Query as the type hint:

Route::get('user/{@User}', function(Query $user)
{
    // Because of the fact the the type hint references a Query instance, we are
    // passed in a query which is setup with all where clauses already set.
    $user = $user->where('admin', '=', '1')->get();
});

[franzliedke]

@JoostK To be honest, I'm not totally sure this kind of code belongs into a controller. But I agree it would be pretty cool, though I'm afraid that it couldn't be as flexible as it would need to.

[JoostK]

If you don't do it like this you still need to setup all your routes to manually specify the model's secondary keys. If an extra field is necessary for the model, you only have to change the model definition and you would be done. This really extracts all boilerplate code of fetching a model.

There is a problem I just thought of, my approach doesn't cope with @taylorotwell's approach of using contracts to fetch a user, not messing with any ORM directly. I believe however that this can still be done when you don't supply a type hint, as you can then still use the passed associative array to pass to the contract implementation.

[franzliedke]

Can you expand on the contracts approach?

[JoostK]

You've probably already seen it but here you go: http://vimeo.com/53029232

[JoostK]

I now see that I'm taking this a lot further than you proposed. I didn't keep in mind that in L4 passing of arguments has changed from index-based to being associative.

[taylorotwell]

@franzliedke in your example of passing model to URL::route, how would it know what to extract from the object, does it extract the properties matching the wildcard segments?

[franzliedke]

Yes, that's the point and the thing that's currently not done (and why we need the models to implement ArrayAccess for an easy solution).

[taylorotwell]

Well, you wouldn't necessarily need ArrayAccess. I do think this is a cool idea though.

[JoostK]

Simply calling toArray will probably do the job? Extra keys will just be ignored by the router I think?

[stephenfrank]

I like the sound of this feature request but, as is stands, the additional key/value pairs in a URL::route() all get appended as a query string.

Route::get('/', array('as' => 'home', function() {}));

URL::route('home', array('this' => 'that'))); // http://example.dev/?this=that

Ignoring all other keys except the ones provided for as URI parameters would break this nifty feature (that I happen to find quite useful). I'd like to see forward/backward compatibility methods considered or maybe it's something that just happens when an instanceof Model is passed into the method.

[franzliedke]

Hmm, good point, @stephenfrank.

I think I mainly wanted to add ArrayAccess stuff to avoid the instanceof thing (and because it would be more flexible, plus convenient). Implementing Iterator might be another option, too.

[JoostK]

I wasn't even aware of this feature, @stephenfrank, good point.