Don't Fear the URLs | Hacker News Reader

Don't Fear the URLs

adam.blog.heroku.com

18 pointssant0sk110 comments

The example may be somewhat literal and simplistic, but I feel the idea has merit.

An interesting direction to keep in mind should the controller logic ever begin too smell spagghetified.

I don't agree with the solution, but he does start off with a good point -- sometimes you have to write a lot of awkward code just to define very simple REST-style resources, whether it's for a public/private api or just some ajax accessible actions for an application.

What's different about the action he describes (and RESTful actions in general) is that the controller essentially gets in the way of accessing the model directly. What he really wants is an rpc call from javascript (or some other internal service), but to do so in the rails paradigm, he has to create a "webpage" which prints out 3.

At the same time though, you might have a resource that requires authentication. If that's the case, the controller has a more obvious role.

I think that Rails controllers do tend to be pretty "fluffy" -- in fact, I would basically call them "view adapters." Replacing them entirely with a Sinatra-style routing and dispatch model would be a fine approach.

However, that still leaves a gap between the page-to-page flow control and transactional logic, which is an area where Rails just doesn't have much help to offer. Having to flatten my entire transaction state into a session hash, which is then (by default) squeezed into a 4Kb cookie, is constraining.

Why not let me instantiate a controller for a particular transaction on the site and control its lifecycle, ala Stateful Session Beans?

That final solution was trash. Decouping can be helpful. For me the biggest is using third-party code. I can have my own URL structure for someone else's app and the views (in Django, aka controllers in Rails) don't change. Having to change every method just to fit into my site structure would be a nightmare. And I don't see a need to tie URLs to my methods, they're not always being called by a URL anyway.

Knowing about available parameters is again not a problem in Django, they are in the method definition. I was pretty sure this was the case with Rails anyway.

And as Chris already mentioned, you can have multiple routes if they are decoupled.

So, instead of having multiple routes, with this method you're locked into one route per action.

That's not true. Have you looked at Sinatra? It's gorgeous. All URI definitions can (and should) be placed in a single .rb file.

  get '/content/:id' do
    header 'Content-Type' => 'text/html; charset=utf-8'
  
    # Get content using params[:id]
  
    if (!@content.empty?)
      erb :show
    else
      redirect '/'
    end
  end

  get '/newstuff' do
    header 'Content-Type' => 'text/html; charset=utf-8'
    login_required

    # Do stuff

    erb :new, :layout => :layout_admin
  end
 
  post '/newstuff' do
    header 'Content-Type' => 'text/html; charset=utf-8'
    login_required
  
    @summary = Summary.new(
      :date => Time.now, 
      :title => params[:title], 
      :author => params[:author], 
      :worthwhile => params[:worthwhile]
    )
  
    # Save content
  
    erb(:new, :layout => :layout_admin)
  end

Sounds nice, although I do like controller inheritance, the ability to mix modules into your controller's scope, etc.

Looks like he wants Sinatra.

This is retartded. You might aswell define your "routes" with mod_rewrite. (or equiv)

Tip: always remember to use spellcheck when claiming that other people's ideas lack intelligence.

Reply on news.ycombinator.com