
Don't Fear the URLs - sant0sk1
http://adam.blog.heroku.com/past/2008/8/12/dont_fear_the_urls/
======
KevBurnsJr
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.

------
ericwaller
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.

------
rcoder
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?

------
jonknee
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.

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

~~~
delano
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

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

------
bct
Looks like he wants Sinatra.

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

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

