Proposal: Route Aliases

[Bauerpauer]

While mocking up a simple controller, I came across something potentially useful - Route Aliases. Consider the following:

  get "/logout"
  delete do
    session.abandon!
  end

Routes without blocks are added to an array. When the next route is defined w/ a block, any routes in the array can be assumed to be aliases.

Could also be written as:

  get "/logout"; delete do
    session.abandon!
  end

Yea? Nea?

[sam]

Where would we actually use this though?

I kinda don't want to bake in things if there's a good chance it would never actually be used on a green-field project.

Maybe the real issue is that there's no way to "forward" requests right now. What about this instead:

delete do
  session.abandon!
end

get "/logout" do
  forward "/session/delete"
end

Maybe forward is a bad word for it, but you get what I'm saying I'm sure. Basically make the Rack::Test style helpers baked in to the runtime and you can do what you want with it, including the occasional route rewrite (and the target doesn't even have to be in the same Controller).

Whatcha think?

[sam]

Oh, reading that back, maybe rewrite would be a better name for the method?

[Bauerpauer]

Or maybe:

delete do
  session.abandon!
end

get "/logout" { delete }

Where delete ends up calling the method named :DELETE on this controller. Less flexible, but probably fulfills 98% of use cases for the feature I was originally describing.

[sam]

You still need something like rewrite under the covers to support that though right?

Maybe routes should have instance helpers? Define at the class level, call at the instance level. Just like a method. So you could do what you want then.

They'd still have to pass back through the Router since your call might include wildcards...

[sam]

Just to summarize the current status of this one:

If we had instance methods to call the actions that the class methods have defined, then that would be a great way (IMO) to tackle both this issue, as well as provide a solid basis for testing applications.

[fgrehm]

@sam we already have instance methods defined for controllers, they are not that user friendly though, get "posts/:id will become GET_posts__id and get "/" will become GET__root__

[sam]

Right, but I'm saying we should be able to:

get "/" do
  if unauthorized?
    get "/login", message: "You should login first."
  else
    response.render "whatever"
  end
end

So we should have instance helpers that allow you to call the routes you've defined. This would make it easy for action A to call action B, as well as provide a nice way to use Controllers in testing.

[fgrehm]

anyone looking into this one? i might be able to handle it tonight ;-)

[sam]

Not at the moment.

Unrelated, but you might want to checkout: https://github.com/sam/jetty-hello-world. I'd be curious what your numbers are if you benchmark it as well. :-)

[fgrehm]

@sam send me the script you used and I can give it a shot ;-)

[fgrehm]

thinking a bit more about this one, i'm not sure if we actually need this... I mean, this scenario could be handled by a before filter or some helper module and I couldn't think about other use case... what do guys think? also, if we add this, what should we do with dispatcher events? should they be fired?

meanwhile, I'll give a shot at adding filters support similar to sinatra have

[sam]

@fgrehm You might take a look at the Harbor::Hooks to bootstrap those filters.

As far as instance methods, I'd like to see them just because it would be really convenient for testing or Console sessions.