Cover me; I'm going in! 6
Mmm… Rails routes, don’t you love them?
Well, not unreservedly, no.
Here’s my current problem: Typo articles have a permalink that looks like /articles/:year/:month/:mday/:permalink, so the permalink for this article is /articles/2007/03/15/cover-me-im-going-in and when someone visits it, the controller gets a params hash which contains keys along the lines of:
- the session, controller, etc }
Which is okay as far as it goes1, but it’s a complete pain when it comes to generating the url. I have to do:
url_for :year => @article.year, :month => @article.month, :mday => @article.mday, :permalink => @article.permalinkEvery value in that hash is dependent on a single object, every key is the same as the method used to find its associated value. I want to be able to write a route that looks like this:
map.article_url \ ‘/articles/:article[year]/:article[month]/:article[mday]/:article[permalink]’, :controller => ‘articles’, :action => ‘show’ article_url @article # generates the routeThat’ll do for starters; I’ll worry about making it Resourceful once I’ve got the basic recognizer and generator working.
So, that’s what I shall be working on within acts_as_resource for the next while. Once I’ve got it working, I’ll start using it within Typo and we can get rid of the various model methods we ended up adding to cope with generating our URLs.
Why bother?
The thing to remember is that, while routes like /:resources/:id are okay when you’re prototyping, they’re problematic for production. Opacity is not a virtue. Exposing internal database keys in the URL is a positive vice.
Meanwhile /articles/2007/03/15, /articles/2007/03 and /articles/2007 all have obvious meanings and typo supplies the obvious index pages when you go to look at them.
1 However, it would be better if it were actually more like: {:article => {:year => '2007', ...}, :controller => ...} because then I can find the article by a simple Article.find(:first, :conditions => params[:article]) and let sanitize_sql do all the work for me.
Pardon my confusion, but I’m having trouble understanding what you mean to convey here. First you say that a route that uses an internal database key isn’t good for production. Then you say that opacity is not a virtue. Then you say that exposing a database key in the URL is a “positive vice”.
Do you mean positive as in good, contrasting with the choice of “vice”? Or do you mean positive as an intensifier? What you say about opacity implies something about transparency, which would seem to indicate you support
/:resource/:id-style routes.I don’t think that a programmatically generated integer used solely to uniquely identify a row in a table can ever be described as anything but opaque. Exposing such a thing in a URL is generally a Bad Thing.
Maybe I should have used ‘meaningful’, or ‘humane’.
Ah, so that makes it all clear. That’s my thinking as well, along with the idea that a programmatically generated value should be used to uniquely identify a row in a table. Sometimes it takes far too much effort to convince someone it’s necessary when there are other convenient values that “will always be unique” and “will never change”.
It was just my misunderstanding with what “opaque” was supposed to mean there. Thanks for the explanation.
When I’m in full on purist mode, I find myself worrying that simple integers aren’t particularly good database keys anyway; if it weren’t for the hassle of dealing with and generating them I’d consider using UUIDs as keys. If nothing else they have the advantage of automatically ensuring ugly URLs unless you do something about it.
If I see a simple integer in a URL like:
/articles/2006/03/15/cover-me-im-going-in/comments/2then I expect that to be the second comment, not the comment with id 2.
I’ve used UUIDs recently, and you’re right on the hassle and the ugly URLs. I mean, unless you don’t see a problem with something like
/users/Jdk98aoODnA37b.Along some of the same lines and as far as the routes go, I must say it’s a bit … let’s say misleading to POST to
/articles/comment/39when leaving a comment on the article with ID 39. But as you say, there are priorities when it comes to working on the routes./articles/comment/39is definitely old skool rails.I remember whinging about it in #rubyonrails not all that long after Rails got released. However, I didn’t do anything about it and I’m eternally grateful to the original developers of the simply restful plugin for both fixing it and for convincing DHH.