My Secret Life as a Spaghetti Coder
home | about | contact | privacy statement
You know when you see code like this:

class CompulsionsController < ApplicationController
    # ... standard actions above here
    def update
      if params[:obsessions].include?(ObsessionsTypes[:murdering_small_animals])
        handle_sociopathic_obsessions
        redirect_to socio_path and return
      elsif params[:obsessions]
        handle_normal_obsessions
        redirect_to standard_obsessions_path and return
      end
     
      # normal update for compulsions
      @compulsion = Compulsions.find(params[:id])
     
      if(@compulsion.update_attributes(params[:compulsion]))
      # ... remainder of the standard actions below here
  end

and the phrase "WTF were they thinking?" runs through your mind?

I have a theory about that little "pass a flag in the url to skip over the real action and perform a different one" trick I see so often (and have been guilty of using myself).

It's because you've got this omniscient file that knows everything about where to route requests that's not part of your editing routine, so finding and opening it breaks your train of thought.

It's a pain to open routes.rb when you suddenly realize you need a new route.

That got me thinking: Should controllers route themselves? Would it make more sense for a controller to tell the router how each of it's actions should be reached?

In the second edition of Code Complete (that's an affiliate link), Steve McConnell writes about using the Principle of Proximity (page 352) as a way to think about organizing code.
Keep related actions together.
From that point of view, it certainly would be easier to follow along when you're questioning "how do I get to this action?" Further, I think it would help solve the "pass a flag to an action to perform a different one" problem I illustrated in the code snippet above.

It was on my mind over the weekend, so I put together this little experiment to see what controllers routing themselves in Rails would look like. In that repository is a one-controller Rails project which specifies routes to itself using a gem you'll find in vendor/gems/route.

One major drawback to doing routing in this style has to do with nested routes: should a controller that's part of a nested route know who it's parents are? Should a higher-in-the-nest controller know about its child routes? And if you choose one or the other, how would you specify it? What if there are conflicting routes -- who wins out?

It leads to a lot of questions for which I have no immediate answers.

Anyway, what do you think? Would this help solve the problem of recycled routes? Is that even a problem?

What are the drawbacks of such an approach? Do you see any merits?

Hey! Why don't you make your life easier and subscribe to the full post or short blurb RSS feed? I'm so confident you'll love my smelly pasta plate wisdom that I'm offering a no-strings-attached, lifetime money back guarantee!


Comments
Leave a comment

There are no comments for this entry yet.

Leave a comment

Leave this field empty
Your Name
Email (not displayed, more info?)
Website

Comment:

Subcribe to this comment thread
Remember my details
Google
Web CodeOdor.com

Me
Picture of me

Topics
.NET (19)
AI/Machine Learning (14)
Answers To 100 Interview Questions (10)
Bioinformatics (2)
Business (1)
C and C++ (6)
cfrails (22)
ColdFusion (78)
Customer Relations (15)
Databases (3)
DRY (18)
DSLs (11)
Future Tech (5)
Games (5)
Groovy/Grails (8)
Hardware (1)
IDEs (9)
Java (38)
JavaScript (4)
Linux (2)
Lisp (1)
Mac OS (4)
Management (15)
MediaServerX (1)
Miscellany (76)
OOAD (37)
Productivity (11)
Programming (168)
Programming Quotables (9)
Rails (31)
Ruby (67)
Save Your Job (58)
scriptaGulous (4)
Software Development Process (23)
TDD (41)
TDDing xorblog (6)
Tools (5)
Web Development (8)
Windows (1)
With (1)
YAGNI (10)

Resources
Agile Manifesto & Principles
Principles Of OOD
ColdFusion
CFUnit
Ruby
Ruby on Rails
JUnit



RSS 2.0: Full Post | Short Blurb
Subscribe by email:

Delivered by FeedBurner