Yea sorry about the dashes lol - should have said "articleId", etc.

Well yes you have to send through params and perhaps this isn't ideal for a "HTML guy" though I haven't had any issues so far. I normally have my front end dev's use stubs for those links and I quickly add them in myself.

The flexibility comes from being able to change the actual links without having to edit any blade templates or touch your controllers. This has been useful to me many times in the past - especially when clients ask for small things like can we rename "profile" to "account"... and then back to "profile" two weeks later. :)

Edit: I do get what you mean though - it's definitely not ideal. Maybe there's a better way to do it. The biggest problem is that front end dev's need to know about route params (names, how many, where they "live") and that's messy.

I guess if i had to do something like that i would use link_to_route() helper with some proper code indentation.

{{ link_to_route(
    'some.route',
    $var->title,
    [
        'param' => $var->param
    ]
) }}

"The flexibility comes from being able to change the actual links without having to edit any blade templates or touch your controllers"

Ah but you would have to if he asked you to change article/$id to article/$slug, which would involve changing all the blade views. Where as having it in the model, you would just change the contents of that one link() method to use $this->slug rather than $this->id.

Of course that comes with its own drawbacks.

I guess most people are in the same situation as me as having to choose between those three examples in my original post and none being perfect. I was hoping someone had come up with another solution, perhaps not.

If you are using named routes in your views then by updating any of params except the route name you do not have to change anything in the view.

Edit:

One more thing. You do not have to name the routes "with" dots. user.profile works as well as user/profile

@keevitaja Why would you not need to change any of the params? Surely if you change article->id to to article->slug you would have to change that in the view?

It'd be much easier to understand what you're saying if you gave code examples

@robjbrain i was referring to route path.

When you have a route auth/login but you decide that this auth "prefix" is useless and want to convert the route to login you have to update all your views using this route as long as you are not using named routes. With named routes it does not matter what the URI will look like.

Long as you keep the vars in the route the same (order doesn't matter).

Ah okay, I was explicitly referring to the sort of thing we've actually been discussing e.g. converting article/$id to article/$slug. Not something as simple as changing 'auth/login' to 'login', obviously that works quite easily and is a therefore a slightly less interesting example/discussion.

There's only so much you can change before needing to change something in a blade file. There's no way to account for all changes I guess?

@robjbrain Like I said I get what you mean and yes you're right - there's no "good" way to do this right now. It'd be fun to try and figure out a simple and clean solution... if only I had time. :(

@bashy use Wordpress?

please ignore this post

@keevitaja Hate WordPress :)

I always wondered why route('articles.show', [$article]) only use the id attribute of the article model to build the url. For example if my route definition is :

$router->get('articles/{slug}', ['as' => 'articles.show', 'uses' => '...'])

It would be cool if the url was built using the slug attribute of the model. You could even change the parameters of your routes too without changing your views. I guess it's possible ?

@pmall this might be what you're looking for: https://github.com/felixkiss/slug-routes

@pmall personally I'd just go with good old Route::bind() in this case. There's really nothing wrong with having it at the top of routes.php and it makes for less "magic".

@mantasmo yes but I really don't like to tie my model selection in a route binding

@pmall Well... that package does exactly that so it comes down to whatever coding style you prefer. Either way works. :)

Yes I just read the doc this package seems cool

I'm not sure I'm really qualified to pitch in here, as I'm not much of a developer, but the topic interests me, so...

I run a content-based website. To me, there are essentially two types of pages:

• "Application" or "special" pages -- login, signup, account management, etc.
• Content pages

My workflow for these two types is completely different. In one case, I'm a programmer; in the other, I'm a writer.

My content does not live in a database. I just use files. This means my content is version-controlled (in a separate repository from the code).

For content pages, my url is the file name. That's it. If I want to change the URL, I change the file name. Because this will break links (regardless of how you code it), I also maintain a list of redirects from old file names to new ones.

My routing logic works like this: first check any "special" page routes, such as login. If none are found, look for a content page. If no content is found, 404.

The content pages route is the last one in my routes file. It looks like this:

// No "special" routes match, so try matching a content page
Route::get('{path?}', 'PagesController@index')->where('path', '.+');

The PagesController isn't doing anything particularly special:

class PagesController extends BaseController {

 public function index($path)
 {
  $viewPath = \App::getFacadeRoot()->BBappView;

  // Laravel prefers path.file for views, not path/file
  $view = 'pages.' . str_replace('/', '.', $viewPath);

  // Look for a "normal" page
  if ( View::exists($view) )
  {
   return View::make($view);
  }

  // ...otherwise look for a directory, and serve its index file
  if ( View::exists($view . '.index') )
  {
   return View::make($view . '.index');
  }

  // We couldn't find the page, so 404
  App::abort(404);
 }

The first line with "BBappView" is a bit of a hack to do with my link management (redirects, canonicalisation, etc.).