Debuggable Ltd. The Company for all things Debuggable

Important: A while after publishing this post I came up with a solution to the problem which I've documented in this post. "Dessert #11 - Welcome back, Friendly URL’s". So if you're a first-time reader of this article please make sure to read the follow up post as well and leave your comments there.

Usually, I don't really consume the stuff that is being put out by the rails community in terms of blogs, screencasts, or conferences. But yesterday I stumbled across David Heinemeier Hansson RailsConf 2006 Keynote Address (the slides to it can be found here), which I felt was a quite impressive and discussed some of the things I've recently struggled with.

One of the things that caught my attention the most, was DHH's oppinnion on friendly urls. Torward the end of Part 7 he is arguing that identifying Objects via friendly URL's is "just not worth it", and that auto-incrementing id's should be used instead. I've been a long time advocate for the opposite point of view, but those words along with the explanation about how this approach is stupid in the database world, made me changed my mind. But let me explain my personal take on it a little more:

In the past couple of weeks I've used a Model called UrlAlias that hooks into the routes.php and allows the completly free assignment of any public URL to any internal CakePHP url. So for example http://www.my-domain.com/about could be connected to /sites/view/1 internally based of the database table url_aliases. That gave me enough power to assign friendly url's to just about any content of the web site I've been working on. I even had an option for redirectional routing, which means if somebody would go to /sites/view/1 he would be redirected to /about instead. But lord, maintaining this complex setup has been difficult. Because what happens if you take the title of a blog as the url, and the blog title get's edited by the user afterwards? The url changes and previous links break. So I thought, well, if the title changes, remember the old one and redirect requests to it to the new one. Nice, that would even allow me to maintain legacy url's! Hm, but now that I'm doing this, I need to build an interface for this, so the user knows how the internal url system works, and can activley use it to improve the friendyness of his url's. Otherwise he'd soon get lost in the world of multiple aliases for the same content.
But now, one day you want to make an international site, so all the url's should be internationalized as well, right? No problem, just convert all the special characters of the foreign languages into url compatible ones, and make the url internationalization an additional layer of abstraction. Sweet ... or? Am I the only one getting a headache at this point? I hope not.

I mean all of this is really nice, and could improve your url's for humans as well as for search engines. But what you are really doing, is breaking up with a convention! And not just a little "alphabetical order for join table parts"-Convention, but one of the conventions most crucial to the RAD'ness of CakePHP. Breaking up with the routing system means an incredible amount of organizational overhead to any application you might build. I've decided that "It's not really worth" it for my current projects. If I need some /about or /new-product page for public advertising, I can use CakePHP's build in routing system, but for the rest I'll stick to the convention and safe myself hours and hours of programming, debugging and worrying. For search engine optimization, friendly url's would be nice, but looking at the serps (search engine result pages) for the keywords important to me, I realized that this is not the main factor for Google & Co. My time seems to be better invested in making my HTML as semantic and accessible as possible, instead of wasting my times on those stupid url's and get lost in a crazy world where I don't know what url belongs to what controller/action/etc.

What do you guys think about this? Anyone still willing to go through the trouble of "friendly url's" or do you rather go for the RAD'ness and simplicity approach instead?

--Felix Geisendörfer aka the_undefined

PS: Sorry for the long time I've not posted on here. I'm in the United States right now, visiting my host family in Atlanta, so I've been a little busy the last 2 weeks with catching up with old friends and interacting with real-world-models ; ). Expect more good stuff on here again from now on.