Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Already on GitHub? Sign in to your account

Proposal: Route Aliases #36

Open
Bauerpauer opened this Issue Mar 5, 2012 · 12 comments

Comments

Projects
None yet
3 participants
Collaborator

Bauerpauer commented Mar 5, 2012

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?

@ghost ghost assigned sam Mar 5, 2012

Owner

sam commented Mar 5, 2012

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?

@ghost ghost assigned Bauerpauer Mar 5, 2012

Owner

sam commented Mar 5, 2012

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

Collaborator

Bauerpauer commented Mar 5, 2012

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.

Owner

sam commented Mar 6, 2012

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...

Owner

sam commented Mar 13, 2012

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 commented Mar 13, 2012

@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__

Owner

sam commented Mar 14, 2012

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 commented Apr 3, 2012

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

Owner

sam commented Apr 4, 2012

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 commented Apr 4, 2012

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

fgrehm commented Apr 5, 2012

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

Owner

sam commented Apr 5, 2012

@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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment