I like the idea on some level, though I wonder:
How well does it play (API-wise) with the logical extensions of asking
for port, protocol, username & password (HTTP Basic)? Port is
problematic due to the normal /:\d+/ pattern used.
The web server often handles functional redirection based upon host.
The request object will have the various URL components and a filter
could be used to alter functionality based upon those URL components.
All I'm saying there is that there are usually other ways to make
behavior conditional. I do like the idea of being able to put that
sort
of control straight into the routes, but my only objection at the
moment
is syntactical -- not in the current suggestion but the next obvious
improvement to the current suggestion.
Some good points, Rick. I can imagine it will extend to use the
protocol quite easily, since we can search for '//' in the route
string and check to see if there's anything in front of it:
map.connect 'proto://:host/:controller/:action/:id'
The username, password, and port, however, are a bit of a stumbling
block. We *could* just throw them in to the :host (or whatever's
between // and /).
With regard to username and password, I don't think it's wise to
encourage people to route differently based on those variables. A
controller should handle authentication, not the routes.
As for the remaining variable, the port, it seems reasonable to
include it in the :host. Or else we can add another delimiter such
as a pipe:
map.connect 'proto://:host|:port/:controller/:action/:id'
I'd rather this last option than combining the port in with :host.
Combining them might cause difficulty when moving between webrick and
apache/lighttpd.
Duane Johnson
(canadaduane)
_______________________________________________
Rails-core mailing list
Rails-core@lists.rubyonrails.org
http://lists.rubyonrails.org/mailman/listinfo/rails-core
